Junto

Junto Labs · RFC 0001 · Draft

The control plane for work humans and agents share.

Junto runs any workflow that people and agents do together. Every step is a contract that a Human, an Assisted human or an Agent can fulfil, and every transition leaves a signed record of who did what, under whose authority.

Read RFC 0001 github.com/junto-labs

Actor model

One accountable principal for every action.

A step can be done by a person, by a person with their agent, or by an agent alone. The persona is chosen per step and can change without a redesign.

Human

Principal
A person
Delegate
None
Identity
SSO

Assisted

Principal
A person
Delegate
That person's agent
Identity
SSO plus a signed, scoped, short-lived delegation

Agent

Principal
An agent with a named human sponsor
Delegate
None
Identity
Workload identity

No self-approval. An Assisted action counts as the human's own, so a person can't approve work their agent drafted. Every agent's sponsor is the one who gets paged, and the sponsor's trust ceiling caps the agent.

Interface first

Define the step before deciding who does it.

An Interaction Contract sets a step's inputs, outputs, evidence and permitted personas. Humans and agents see the same task and the same definition of done, so moving a step from Human to Agent is a policy change, not a rewrite.

InboxWeb forms for people
CLIText in, JSON out
APIFor systems and controllers
MCPTools for agents
apiVersion: juntolabs.dev/v1alpha1
kind: InteractionContract
metadata:
  name: triage-support-ticket
spec:
  inputs:
    schemaRef: schemas/ticket.json
    knowledge: [support/runbooks, product/known-issues]
  outputs:
    schemaRef: schemas/triage-result.json
  evidence:
    required: [classification-rationale, knowledge-citations]
  actors:
    allowed: [Human, Assisted, Agent]
    default: Assisted
    minTrust: contributor   # per contract, not per install
  review:
    fourEyes: when-outputs.severity in ['sev1','sev2']
  sideEffects:
    - kind: forge.comment   # run by the broker, never the actor
  sla: 4h

Trust model

Trust is enforced by components, not prompts.

Trust is decided per interaction point, not per installation. Each of the four layers is owned by a component, and a missing policy, credential or evidence item blocks the step.

01

Identity

Who is acting, for whom?

SSO for humans, workload identity for agents, signed delegation for Assisted.

02

Authorization

May this actor do this step, now?

Kubernetes RBAC for the API and CEL policy for contract-level rules.

03

Containment

What if the actor misbehaves?

A Pod per agent run, egress through a broker, and no write credentials for actors.

04

Evidence

Can we prove what happened?

A signed, hash-chained evidence bundle for every transition.

Earned autonomy

Each actor and contract pair has a trust record built from approvals, rework, escalations and overrides. A human approves each promotion, and demotion happens automatically when the score drops below the floor.

Four-eyes is a platform rule

Approvers are always a different principal from the author. Irreversible steps, like merging to main or replying to a customer, need a human approver until a policy says otherwise.

Components

Small tools, each with one job.

Each component is one binary that runs alone on a laptop, in CI, inside Claude Code or on Kubernetes. They share nothing but JSON Schemas and connect only through files, JSON, exit codes, events and MCP.

Baton

Workflow definitions and run state. Nodes are tasks, decisions, gates and waits that reference contracts, and gates are judged by the engine, never by the actor that did the work. The same workflow YAML runs from the CLI, over MCP or as a controller.

# a gate is just a command and its exit code
baton gate add spec-ready \
  --cmd 'knowtorious lint --space product --max 0'
Phase 2 · rebuilt from Spektacular
Knowtorious

Scoped, access-controlled knowledge. Sessions start with a table of contents, not content, and agents fetch only the entries their contract declares. Checks run before ranking, so out-of-scope knowledge never reaches a prompt.

go install juntolabs.dev/knowtorious/cmd/kt@latest
Phase 1 · in progress
CruxExists

Agent runtime: one Pod per agent run, with a watchdog and sandbox.

WardenLater

Policy decisions, trust records and autonomy bindings.

LedgerLater

Append and verify signed evidence and the audit trail.

BrokerLater

The only holder of write credentials; performs side effects.

IntakeLater

Pulls work items from GitHub, Linear, Jira and support desks.

junto-specSchemas

The shared vocabulary: JSON Schemas and nothing else.

Unix philosophy

Pipes, not plumbing.

  1. 01
    Text in, JSON out. Human text by default, --json on request. Exit 0 passes, 1 fails, so any tool can be a gate.
  2. 02
    Plain files first. State lives in a folder you can diff and review. Postgres and CRDs are opt-in backends.
  3. 03
    Absent neighbours are fine. With no Ledger, evidence goes to JSONL. With no Broker, side effects print as a plan for a human.
  4. 04
    Four faces, one core. Every binary has a CLI, an MCP server, a Claude Code plugin and an optional controller.
# evidence flows from one tool into another
knowtorious search 'refund policy' \
  --space support/runbooks --json \
  | baton pass --run r-42 --evidence -

# every pass is recorded, without Baton
# knowing that Ledger exists
baton log --run r-42 --json \
  | ledger append --stream runs/r-42

Roadmap

Each phase ends at a gate we can demo, not a date.

Junto is built with Junto. Each phase moves more of our own development onto the platform, starting with Knowtorious and Baton, and every gap we hit becomes an issue against Junto.

  1. 1 · Knowtorious v0Now

    Read-only list, get and search over a markdown vault, with an MCP server and a Claude Code plugin.

    GateAn agent completes a task by fetching only the entries it needs, with no knowledge in CLAUDE.md.

  2. 2 · Baton

    The engine, CLI, MCP and plugin; Interaction Contracts; Spektacular's flows as the engineering pack.

    GateSpec to merged PR, with four-eyes enforced by the platform.

  3. 3 · Knowtorious v1

    Agents propose drafts, approved through a Baton four-eyes gate; then spaces and grants.

    GateNo entry is approved by its author, and an agent reads only what its contract declares.

  4. 4 · Full loop

    Support and product packs, a support desk adapter, and Ledger, Broker, Intake and Governor.

    GateA ticket becomes a fix and the customer is told, on one signed evidence chain.

  5. 5 · Earned autonomy

    Warden trust records with automatic demotion, human-approved promotions, and controllers.

    GateAutonomy changes are driven by evidence, not configuration.