Community

In brief

Any Work System — human, agentic or mixed — is understood by answering six questions. A Formation is a declared arrangement for coordinating participants: coordination, not work. It answers how the work progresses, what gives the go-ahead, and what makes the result official. “Agentic” is not itself a Formation.

The Work System stays the one canonical object. Model, grounding, authority, simulation, cost, security and realization each read the same model rather than keeping their own copy of the enterprise.

• What is the work? · How does the work progress? · Who participates, and how are they related?
• What grounds the work? · What gives a participant the go-ahead to act? · What makes the result official?
• Formations: defined in advance · decided as it happens · the work organizes itself

In brief

Agent platforms supply each agent’s loop and sandbox. None supplies the layer above — what runs next, whether a gate passed, what state carries forward, and who handles the steps a model must not. That layer is where the design lives, so it has to work the same whichever platform runs each agent.

• Design — the canonical workflow model, simulated against today
• Realize — a specification an agent platform can build from; every field specified, inferred or left to the builder
• Deploy — packages for LangGraph, the OpenAI Agents SDK, Claude Managed Agents, n8n and AWS AgentCore
• Run — real work, human steps kept human, modeled vs realized measured

Design, simulation, the specification and the packages work in bot0.ai today. Running a designed workflow end to end — starting with Claude Managed Agents — is being built now.

In brief

A grant says what the agent may do, what it must ask about first, what it must never do, and what makes a result official — as a letter a person can read, rules the agent can follow, and a fingerprinted file a system can check. A pure verifier answers Allowed, Ask first, or Not allowed for any proposed act.

• Specification, JSON Schema and an RFC 9396 authority type
• Per-act authority: who does it, with whom, on what facts, within what limits
• A free writer that runs in your browser — nothing is sent unless you choose to

From the project README

Most orchestration stacks already track state (graph checkpoints, crew context, Temporal workflows, hosted chat sessions). What usually stays coupled to one runtime is the meaning of that state: who is foreground, what is pinned, and how resume/handoff work across specialists.

This package makes conversational authority an independent contract: single-writer decide_turn, thin projection (L1) + event journal (L2), COMPLETE ≠ ABANDON, multi-task suspend/resume. Semantic interpretation stays with the LLM; who owns the thread is code-owned. Persistence is assumed — DB-backed is not the USP; portable authority semantics are.

• claim → decide_turn → handle → apply → release host cycle
• Cross-runtime authority (same law if the run leaf changes)
• HITL-ready · multi-task foreground · KindSpec + thin pins

From the project README

In multi-turn agents, the reply can sound correct while the conversation machine underneath is wrong. Those are ledger and handoff bugs, not bad writing. Unit checks and LLM-as-judge evals usually miss them.

Principle: LLM proposes · code enforces. Conjecture regression-tests the enforce half after each scripted turn (owner · pin · handoff). Owners, kinds, and pins are host vocabulary — not a fixed Conjecture catalog. Pair with separate classifier tests for cognition drift; use Conjecture for “given these labels, did code still seal the ledger?”

• Script · Turn · Driver · Observation · Invariant
• Healthy-PASS / planted-FAIL discipline + CAQ-FM taxonomy
• Ledger-store agnostic if Act projects owner/pins (DB, LangGraph, Temporal, …)

MIT · 0.1.6. Demos use sample kinds (e.g. cost_out) only as stand-ins — substitute your exclusive_owner and pin keys.