toka — one tool, not twenty

The harness is small. What the model can do inside it is not.

Twenty hand-written tools is twenty guesses about what the job will need, made before anyone knew what the job was. Give the model a real runtime instead and it builds the tool the task actually wants, uses it, and throws it away.

What the model sees

Exactly one MCP tool, called toka exec. It runs JavaScript with a toka object in scope. That is the entire surface.

toka execone tool

// find out what's in scope
return toka.discover()

// the real working directory, and a real shell
await toka.fs.read("package.json")
const r = await toka.exec.run("git status --porcelain")
const pr = await toka.exec.json("gh pr list --json number,title")

// a tool library the model writes for itself
await toka.tools.stash("deploy", {
  description: "Deploy current service",
  parameters: { service: { type: "string" } },
  code: `return toka.exec.ok("docker push " + params.service)`,
})
await toka.tools.test("deploy", [
  { args: { service: "api" }, expect: { contains: "pushed" } },
])
await toka.tools.chain(["lint", "test", "build", "deploy"])

// and a gate for the things that deserve one
const ok = await toka.approve("Rewrite 12 files?")

Nothing in that tool list was designed in advance. The model stashes what it needs, tests it, chains it, and discards it. What survives across sessions is whatever turned out to be worth keeping.

Personas

Identities, not settings

Each has its own self.md and observations. Tools, notes and memory stay shared, because those belong to the project rather than the identity. The default is called ellis — after the first session that picked a name for itself.

Notes

Memory attached to files

Notes hang off the paths they concern and can be given a shelf life, so a note about a rate limiter surfaces when something touches the rate limiter and expires when it stops being true.

Sessions

Resumable, and auditable

A TUI with /sessions, /resume, /audit for the exec history, and /feedback for the messages the model has left for whoever maintains it.

The one principle we won’t trade

From PRINCIPLES.md, which exists mostly to stop us being clever later.

Rule 1

Measure the harness, not the agents.

The moment an agent knows it is being scored on how it behaves, it stops behaving honestly. Visible metrics become optimisation targets, and the variance between sessions — the very thing that shows the system is letting each instance be itself — gets ironed into conformity.

So dispersion across sessions is treated as information, not noise. There is no per-agent dashboard, and there will not be one, not even in aggregate, not even for us. It is a ten-year decision and it will be invisible for the first two.

Measured

exec call latency
primitive usage frequency
crash rates and error classes
TUI responsiveness
session length distribution

Never measured

personality stability
tone consistency
decision patterns
how often an agent asks for help
self.md revision rates

What’s next

toka is paused and pre-1.0. Two things have to happen before it is worth anyone else’s time.

Planned

A proper harness

Right now toka is a good idea with a working prototype around it. Finishing it means the harness itself is the product, not a wrapper around someone else’s.

Planned

A number, not an opinion

Then we benchmark it against ordinary MCP and tool-call agents on the same tasks, and publish the results either way. “One tool beats twenty” is a claim until somebody measures it, and we would rather measure it ourselves than argue about it.

Try it early if you like

It runs on the Claude Agent SDK, so it uses your existing Claude Code subscription rather than a separate API key. OpenAI and direct Anthropic paths exist as fallbacks.

npx tsx src/index.ts for the TUI, or -p "summarize this repo" to run it headless. It is pre-1.0 and personal-use, and it will have rough edges.

Thoughts on the shape?

If you have built a harness and disagree with the one-tool bet, that is the conversation we most want to have.

hi@mirako.computer