all projects
llm-intelligence-layer
multi-agent runtime with a real separation between advisory and acting traffic — plan → human approval → tools → publish, holds as durable graph interrupts, not ui checkboxes.
one conversational control plane where an analyst can ask (read-only guidance) or work (structured assessment with human-approved actions), backed by the same agent runtime. a generic platform with a pluggable domain pack; it ships a worked example for security and compliance incident triage.
what it does
- two modes, enforced structurally — scout is the default and never constructs the tool-calling graph at all, so “default traffic cannot mutate anything” is a fact about the api layer, not a promise in a system prompt. operator is the acting path and requires an explicit operative.
- the acting pipeline — classify → plan → hold → run tools → seal → land. the classifier (herald) sorts each turn into scan, act, or weave; a planner drafts steps; then two human-approval gates bracket tool execution and publishing.
- holds are interrupts — the graph pauses, a pending-approval row exists in postgres, the analyst decides through the console, execution resumes. every mutating action carries a human decision attached, before the effect happens.
- the rest of the platform — mcp tool servers (platform-scoped and case-scoped), pgvector rag over an archive, an isolated codegen sandbox worker, and an openai-compatible model gateway so providers are configuration not surgery.
what testing it forced
the eval suite proves the shape of the flow: an act turn produces a plan hold, then a publish hold, and publishes only after both approvals; rejection produces zero tool calls. writing that test is what surfaced the gap worth knowing about, the tool layer’s read/write verb field was documentation rather than enforcement, and closing that in the executor rather than the topology is the lesson i carry into every agent system since.