Build & ship · Developer tools
Coding agents
Agents that follow a staged workflow for the kind of work they are doing, running on local models, governed by consent and trust, with every action logged.
What it is
An agent is a local LLM running in a loop: it receives a task, calls tools to gather information and take action, checks its own progress, and either finishes or asks for help. It runs on the device's own local model rather than sending the work to an outside service, though a cloud model can be configured as a fallback. Every tool call is logged as its own event in the shared history, so any session can be replayed to see exactly what the agent did.
What a person notices
Launching an agent means giving it a task and a role. The role is not optional decoration: it is what limits which tools the agent is even allowed to try.
A sensitive action, such as writing a file or running a shell command, triggers an approval prompt. The person approves or denies each one; the agent waits.
An agent that writes code works in its own isolated copy of the repository, separate from the person's own working copy. Nothing lands until the person reviews and merges it.
Long-running agent work streams progress back live rather than leaving the person staring at a spinner, and the whole run can be inspected afterward as a signed audit trail.
What you get as a developer
The staging comes from three things working together: a role that fits the kind of work, a workflow engine that enforces step order, and a quality check before the result counts as done.
Pick a role for the kind of work
A worker role gets coding tools, a critic role gets read and search plus enough to analyze, a facilitator role gets orchestration tools including the ability to launch further agents. The role's own tool grant is what is enforced, as a hard limit the agent cannot talk its way around.
Trust gates what happens next
Agent trust is rated on a scale, and the rating is what unlocks each tier of capability: read-only at the bottom, then write access, then operations on the shared history and workflow navigation, then full orchestration at the top. Trust is checked on every single tool call throughout the session.
Multi-step work runs through the workflow engine
For work that spans several steps, the same engine that manages procedures and roadmap items advances the agent through its steps in order, checking prerequisites as it goes, so a multi-step task cannot skip ahead of itself.
A quality check runs before the result counts as done
After the tool-calling loop ends, the output is scored and comes back with a recommendation: accept, review, reject, or retry. Finishing the loop does not by itself mean the result passed.
A facilitator can delegate to worker agents, but delegation depth is capped: facilitator to worker, no deeper. A runaway or stalled agent process is detected and stopped rather than left to spin.
Launching an agent, in the shape your own tooling would send
This is the real entry point for agent execution: one tool, a prompt, and a role.
{
"tool": "agent.execute",
"arguments": {
"prompt": "Review the test file for any issues",
"role": "design-critic"
}
}
The role is required; there is no default role an agent falls back to. Passing a narrower tools list restricts what the agent can call further, but it can never add a tool the role itself was not granted.
How it relates to other steps
CI
Agents and CI runs both draw on the same kind of pooled machine time inside a Hive; a package's tests and its agents can share a Hive's resources rather than needing separate infrastructure.
Work together
An agent that needs to participate in a conversation joins a Hive channel the same way a human does, through an explicit approval every time.
Package manager
Model packages that back an agent's local inference go through the same install and approval path as any other package.