Most of them are a prompt template and a loop over one model API — no durable state, no answer for a run that dies mid-flight, no record you could hand an auditor. This page is the answer we want you to check: three runtimes under one audit surface, state in Postgres, and governance in the tool-call path itself.
The questions a technical evaluator asks — where does state live, what happens on failure, what gets recorded, what stops a bad write — are exactly the questions a wrapper can't answer, because the model API underneath it answers none of them.
So we built the layer that does: durable execution engines fitted to the shape of the work, checkpointed state, an audit logger inside the run loop, and a policy gate at the exact point where an action becomes real. Models stay swappable; the runtime is the product.
A fixed procedure, a routed conversation and a delegated role are different execution problems. Each gets the engine built for it — and all three run inside the same governance gates and write to the same audit trail.
Ordered procedures execute as a compiled LangGraph: the same tasks, in the same order, every run. Tool calls stream as they happen, mutating tools are classified and gated, and untrusted tool output passes the prompt-injection shield before it re-enters the model's context.
Multi-specialist conversations run on a LangGraph orchestrator with a supervisor node deciding which specialist owns each turn — deterministic execution plans (sequential, hierarchical, hybrid) or intent routing. Session state checkpoints to Postgres, so a conversation survives its process.
An employee's task plan is handed whole to an autonomous agent runtime (built on Agno) carrying four toolkits — tables, agents-as-tools, knowledge bases, and integrations over MCP. It executes in the background on Celery, pauses for human input when policy or plan requires it, and resumes where it stopped.
Engines: LangGraph for sequential and team runtimes; Agno for the employee runtime. One audit surface across all three.
Whatever the runtime, every unit of work moves through the same loop — and the governance check is a step in the loop, not a review after it.
Pull the request and its context: inputs, the tables it's permitted to see, knowledge retrieved by hybrid search, and — for employees — memory from prior sessions.
A procedure follows its fixed graph; a team's supervisor routes the turn; an employee's planner emits a step list its runtime executes autonomously.
Before a tool call executes, the policy engine evaluates it and the runtime authorization floor checks writes. Held calls wait for a human; the verdict is logged either way.
Call the tool, run the sub-agent, read or write the table — inside the grant, with the injection shield screening what comes back.
Tokens, tool calls, handoffs and agent transitions stream to the client as typed SSE events while the run is still moving.
Every tool call lands in the audit trail with sanitized inputs and outputs, read/write classification, token and dollar cost — pinned to the config version that ran.
The policy engine and the runtime authorization floor sit in the tool-call path, inside the runtimes — a call is evaluated at the moment it would execute, unapproved writes are a no-op, and tools without schemas are wrapped so nothing routes around the gate. The prompt-injection shield screens tool output before it re-enters a model's context. That placement is why the same rules cover chat, schedules, triggers, the API and MCP clients identically. The governance layer →
The question that separates a demo from a platform. State here is durable rows in Postgres, scoped to your org and workspace — so failure is a resume, not a restart.
Team conversations checkpoint to Postgres per session thread. A follow-up message resumes from the last checkpoint — current agent, plan position, conversation state — not from a blank context. Kill the process mid-run and the session is still there.
AI employee tasks are queue-backed rows, not in-memory promises. A task waiting on human input parks with its working memory intact and resumes from the same runtime when the answer arrives.
Trigger-fired executions run on Celery and retry on failure with exponential backoff. Every firing — including the ones that were filtered, debounced or rate-limited — lands in a ledger, idempotent by provider event ID.
Tool-call records buffer in memory during the run and bulk-insert at run end — near-zero overhead in the hot path, and the trail exists whether the run finished, failed or was halted by a breaker.
Six mechanisms a technical buyer should verify in any platform claiming to run an AI workforce. Here's our answer to each.
Real server-sent streaming with a typed, handoff-aware event model — agent start, tool call, token, handoff, done — persisted per session for historical replay, not just painted on a socket.
Short-term conversation window, working memory scoped to the active task, and long-term facts, preferences and standing instructions — retrieved by importance, recency and access frequency.
Dense vector search combined with Postgres full-text search and rank fusion, so exact identifiers — SKUs, ticket numbers, names — are never lost to embedding fuzz. On the default engine.
Token counts, duration and USD cost recorded on every message, aggregated to session and team, with hard budget caps and cost circuit breakers watching the totals live.
The audit logger is instantiated inside all three runtimes, not scraped from logs afterward. Every tool call is captured, sanitized and classified at the moment it happens.
30+ tools over a standards-compliant MCP endpoint: agents, teams, employees, tables, knowledge and runs are programmable by other AI systems. A substrate, not a dead end.
Honest footnotes: hybrid retrieval is active on our default vector engine; other backends fall back to dense-only search. Voice runs via a deployed voice worker, not an in-chat button.
Every claim above reduces to one of these — and each is enforced by a mechanism you can locate in the run loop.
Org → workspace isolation on every object, per-agent Read / Create / Update / Delete on tables, tool grants per worker. Least privilege, enforced server-side.
Policy engine plus a runtime authorization floor in the tool-call path. An injected or unapproved step can't perform a side effect — approval is checked where the action happens.
The audit logger runs inside all three runtimes: every tool call sanitized, classified read-vs-write, PII flagged, pinned to an immutable config version.
Token and USD cost on every message, hard daily and monthly budget caps, and circuit breakers that auto-pause a worker when a cost or error threshold trips.
