Baton · a protocol for governed AI

Why did the system send that email?

BATON, Bounded Authority for Traceable Orchestrated Networks, is a vendor-neutral standard for teams of AI agents. Every unit of work is scoped, every interaction between agents is recorded, and every action that touches the outside world is authorised and metered. So that question always has an answer.

Read the research Talk to the team

Invariants enforced in code

Rules the runtime guarantees, not guidance in a doc.

I/O in the core

No database, HTTP client or model provider baked in.

100%

Of hand-offs recorded

Agents can't reach each other, so every exchange is a trace.

Spec

Available on request

A protocol plus a reference implementation. Public release is planned.

The problem

Agents that call each other leave no trace.

Most agent frameworks let agents call each other directly. That works until someone asks why the system did something. Direct calls leave nothing behind, so the answer has to be rebuilt from logs, if it can be rebuilt at all.

Baton makes the trace structural rather than optional. Specialists can't reach one another, so every piece of data that moves between them is a durable, attributed, ordered blackboard entry, and every request for another capability is a recorded delegation. Auditability is a consequence of the architecture, not a logging habit someone has to keep up.

How it works

A blackboard, not a phone line.

One orchestrator owns all authority. Specialists each see only their slice of the task, write to a shared blackboard, and anything with a side effect waits for a person.

Your request"Compare the supplier quotes and email the best three"

OrchestratorSplits the task, orders the steps and owns all authority. The only thing that can start a specialist.

Analystsees: prices, terms

Researchersees: supplier names

Writersees: scores, template

BlackboardAppend-only, attributed, ordered. The only channel between specialists. Every fact shows who wrote it and when.

Approval gate"Send 3 emails?" waits for a person, for hours if needed, then resumes exactly where it stopped.

ContextEnvelope

The record of one task

Versioned and persistent: the intent, how it was broken down, known gaps, shared facts and spend.

ContextSlice

Need-to-know context

The bounded view a single specialist receives. An analyst sees the quotes, not your HR records.

Blackboard

The only channel

An append-only, visibility-controlled fact store. It belongs to exactly one task and one tenant.

Orchestrator

Sole source of authority

The only constructor of specialists. It owns authority and the order in which work depends on other work.

AgenticLoop

Suspendable by design

A tool-calling loop that can pause for human approval and resume from storage, even after a restart.

TaskBudget

One budget per task

Token, tool-call, spawn and depth ceilings shared across the whole task tree, so a team can't run away with your spend.

The invariants

Eleven rules. Enforced in code.

These aren't best practices. The reference implementation refuses to run anything that breaks them.

A specialist never holds a reference to another specialist.
All data between specialists flows through the blackboard.
Delegation is limited to declared capabilities, is never cyclic and never exceeds the depth limit.
Every specialist receives a context slice, never the full envelope.
Token, tool-call and spawn budgets are shared across the task, not per specialist.
Side-effecting tools pause for human approval, mid-loop and resumably.
A specialist's usable tools are its declared set intersected with what the person actually authorised.
Every model call is metered against the person who asked, with idempotency keys.
A blackboard belongs to exactly one task and one tenant.
Output is validated against its declared schema before anyone can see it.
Blackboard and run state survive process restarts.

Human approval

A "no" isn't a failure.

An approval can take hours, far longer than any request or worker lives. So Baton never holds the loop's position in memory: the paused run is saved with the task and picked up exactly where it stopped once a person decides.

Pauses mid-stepSending, paying or writing to a system stops and waits for sign-off.
Resumes from storageSurvives restarts, deploys and overnight waits.
Denials feed backThe specialist gets the refusal as a result and adapts, or finishes without that action.

Baton · Supplier outreachPaused

Analyst scored 12 quotes
Wrote 12 scores to the blackboard.

Researcher checked the top three
Saw supplier names only.

Writer drafted three emails
Validated against the output schema.

Send 3 emails
Side effect: waiting for your approval.

EditDenyApprove & resume

Fits your stack

No I/O in the core.

Baton has no built-in dependency on any database, HTTP client, model provider or cloud. Everything external is an interface you implement against your own systems, so the same guarantees hold in Verkko Cloud, your own cloud or an air-gapped install.

Pluggable gatewaysModels, tools, approvals, usage metering, storage and memory.
Reference test doublesIn-memory implementations define the expected behaviour and test your adapters.
Safe upgradesMinor versions only add fields, and readers keep fields they don't recognise, so services upgrade one at a time.

# Reference implementation (Python)
registry = {
  "analyst": SpecialistConfig(
    capability="analyst",
    tools=("quote_parse",),
    can_delegate_to=("researcher",),
    context_keys=("category", "budget"),
  ),
}

orch = Orchestrator(registry, deps)
outcome = orch.run_task(envelope)

if outcome.suspended:
  store.save(envelope)  # waits for a person
  ...
  orch.resume_task(envelope, sub_id,
                   approved=True)