Capabilities overview
A conceptual tour of what the platform does. For how the pieces compose internally see the Architecture page; for what is live versus roadmap see the Status ledger.
The three dials
Dial 1 — Tier (the model dial)
Each request is scored by an intrinsic difficulty signal computed from the request
input alone — length, code and reasoning markers, output-length band, and tool usage. That score
selects a low / mid /
high tier, with an optional dynamic escalation up the tiers for the harder
tail. Callers can clamp a quality floor (min_tier) and a cost cap
(max_tier). The response reports which tier actually resolved, whether it
escalated, and the price. Model aliases are cognitum-auto / low / mid / high
— raw vendor model ids are never exposed.
Dial 2 — Host (the runtime dial)
A pod can be driven by different agentic runtimes ("hosts"). Whichever host drives the loop, it is pointed back at the gateway, so every model call stays tiered, metered, and budget-capped no matter which runtime is in the driver's seat. Host choice is itself a measured cost lever — a heavyweight scaffold can force a more expensive tier, so the platform treats host as a first-class axis. An unavailable host pauses the pod with an audit warning rather than faking a result.
Dial 3 — Approval gate (the safety dial)
When a pod step proposes an action that trips its configured gate (for example, anything irreversible or outward-facing), the pod parks in an awaiting-approval state. It holds a worst-case budget reservation — reserved, not spent — and posts a signed proposal. A human resolves it:
- Approve → commit the held reservation at the real step cost → the pod resumes.
- Reject → release the reservation (spend nothing, zero outward effect) → the pod resumes.
- Timeout → auto-reject (fail-safe; never auto-approve) → the pod pauses.
Darwin-Loop pods
A pod is an autonomous agent loop defined as pod = {domain × host × tier}.
The engine drives a step lifecycle — spawn, execute, evaluate, idle — where each step is a real,
metered, budgeted model call. A behavioral bench scores the captured artifacts of each step against the
pod's contract; a non-conforming result escalates the pod. A runaway pod that exhausts its budget
pauses at a bounded spend rather than running away.
Metering & budget governance
Family-correct metering
Every request is tokenized with a family-correct progressive tokenizer and booked into a usage ledger. The local count is the billing floor on disconnect or truncation; the provider's authoritative count is preferred when available.
Reserve-and-Commit
An atomic two-phase budget tracker reserves a worst-case estimate before the call and commits the actual cost after. Sharded per agent so high-concurrency loops don't contend; an account hard-cap is the final backstop.
Rate limiting
A scatter-gather limiter bounds throughput without serializing on a single counter, with tenant-scoped idempotency keys to dedupe retries safely.
Self-calibrating flywheel
A calibration pass turns assumed routing parameters into measured ones from the usage ledger and hot-reloads them — a recalibration takes effect with no redeploy.
Business-autopilot vision
The gated, metered pod substrate is the foundation for a longer-term business-autopilot layer: domain-scoped pods (sales, finance, support, ops) collaborating across human-facing surfaces, each irreversible step routed to a person for approval and every dollar governed. The platform owns the approval-gate seam today; the human-facing surfaces and business templates are design-stage. The Status ledger states exactly which pieces are live, built, or design-only.