kodo

kodō, heartbeat kōdo, code

A heart made of kodo's source code, beating at 60 beats per minute above a heart monitor trace.

what it does
Truemed, agentic

A development loop for cloud agents, on our own terms.

kodo is how Truemed runs agentically. Cloud agents work in exactly our codebase, running exactly the way we run it. It isn't an approximation or someone else's sandbox. It's our tool, and we use it however we see fit.

  1. spin up

    kodo starts Truemed in an environment of its own, on seed data.

  2. change

    An agent changes the code, migrations included.

  3. validate

    The agent proves the change works. If it doesn't, it changes it again.

  4. learn

    What it learned goes into kodo's shared memory, so the next agent starts smarter.

↻ one beat per step

What kodo does

kodo builds Truemed on demand.

Ask for an environment and kodo assembles a complete, isolated copy of Truemed's stack on a box of its own: mono and marketing-mono at the refs you choose, with their database beside them. Then it hands that box to whoever asked, whether that's an engineer at an ssh prompt, an automation, or an agent free to explore.

  1. 01

    You ask.

    In Slack, you mention @kodo or type /kodo. /kodo env up asks for a box and nothing more. From anywhere else, you post JSON to /v1/jobs. Plain words are the request, and anything structured rides along as context.

  2. 02

    kodo spins up Truemed.

    One EC2 box, launched from an image kodo bakes every hour, with mono and marketing-mono already installed. Boot checks out your refs, brings up Postgres on the box from seed data, and starts the app, the API, and the marketing site. Agents run migrations freely and real member data is never near them. The agent starts by reproducing the problem.

  3. 03

    An agent makes the change.

    Before touching anything, it reads what earlier agents learned about the parts of Truemed it's changing.

  4. 04

    kodo validates it.

    Tests, migrations, and the running app, all on the same environment that reproduced the problem. A failure sends the agent back to the change, up to a limit.

  5. 05

    kodo weighs the risk.

    A policy in the repo makes the call from what changed: which paths, how much, how well tested, and who owns it. The agent can make the call more cautious, never less.

  6. 06

    kodo ships it or shows it.

    The agent opens a pull request with a preview URL for a person to review.

  7. 07

    kodo learns and reports.

    The agent records what it learned about how Truemed works. kodo replies with the diff, the evidence, its risk call, and the link. The box stays yours: it goes to sleep when no one is using it and wakes when you ask.

Your own Truemed

One box per thread, with the whole of Truemed on it.

Every Slack thread gets at most one environment, and it belongs to the thread. Engineers ssh in over Tailscale as dev and find both repos on a branch named after the box, with Claude Code installed. Jobs in the thread reuse the same box. Idle for two hours, it goes to sleep with its disk intact. Say env start and it is back in a minute. After a week it is gone, and its branches are pushed so nothing is lost.

slack/kodo env
/kodo env up mono@my-branch
kodokodo-x7k2m9 is ready. app http://kodo-x7k2m9:3000 · api :8000 · marketing :4200 · ssh dev@kodo-x7k2m9in the thread
sshtailscale
ssh dev@kodo-x7k2m9
# ~/mono and ~/marketing-mono on branch kodo/kodo-x7k2m9
cd mono && claude
requestedbuildingreadyasleep
Shared memory

Every change leaves kodo smarter.

At the end of every job, the agent writes down what it learned about how Truemed works. Learnings live in kodo's database, searchable by people and agents alike, and every new agent reads the relevant ones before it starts.

recordPOST /v1/learnings
# at the end of a job
{
  "topic": "Adding a column",
  "body": "Add it nullable, backfill,
           then add the constraint.",
  "repo": "mono",
  "tags": ["migrations"],
  "job_id": "92b757fb-…"
}
recallGET /v1/learnings
# before the next one
GET /v1/learnings?q=migrations&repo=mono

# best matches first
{ "learnings": [
    { "topic": "Adding a column", … },
    …
] }
Every request keeps time

Nothing is lost, and nothing runs twice.

kodo records every job the moment it arrives, follows it from start to finish, and reports back where you asked: in Slack, or at GET /v1/jobs/{id}. When Slack retries a message, kodo recognises it and lets it pass.

receivedrunningsucceeded
Two ways in

Slack is one caller. Anything can be another.

People talk to kodo in Slack. Automations talk to it over a small JSON API with a bearer token. Both become the same job.

slack/kodo
/kodo spin up mono at PR 1234
with the shopify extensions
kodoOn it.only visible to you
httpPOST /v1/jobs
curl https://kodo.truemed.com/v1/jobs \
  -H "Authorization: Bearer $KODO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"text": "spin up mono at PR 1234",
       "context": {"repo": "mono", "pr": 1234}}'
# → 202 {"id": "92b757fb-…"}