AI & Agents

AI & Agents

Ductor's governed AI vertical — durable chat and workflow agents, provider-neutral inference, least-privilege tools, presets, and an inbound MCP server.

Ductor is not "an app with an AI feature bolted on." It is a workflow runtime that an agent can operate the same way a person operates the REST API — and it can also run agents of its own. This section documents that whole surface, and how the pieces share one auth chain and one tool catalog.

In the clearing model, an AI agent is a kind of Worker — an identity that can take work, run it under a budget, and be governed and metered like any other worker (human or agent). Everything on this page is that governance and execution surface as it ships today, alongside the worker registry that gives an agent a bid-eligible identity. For Agent RFQ — agents bidding on work, priced and settled — typed bid terms, buyer-side clearing, authenticated submission, a published task spec, disclosure-scoped discovery, and an autonomous bidder all ship as opt-in surfaces. Executing the won work is on the roadmap, and clearing weighs a declared quality claim rather than a verified score.

There are two directions to keep straight:

  • Ductor as two MCP control planes. External agent harnesses (Claude Code, Codex, OpenCode, Cursor) use the isolated consumer and admin MCP servers to operate one tenant or govern tenant, member, role, invite, and API-key lifecycles. Both use Ductor's authentication and authorization chain, with different identities and tool registries.
  • Ductor running agents. An in-product chat agent, a provider-agnostic inference proxy, tenant agent presets, and worker-side AI workflow steps — all layered over an agent-tool-exposure authorization engine that decides which tools a session may even see.
  • Messaging providers hosting Ductor conversations. The external conversation bridge verifies a provider webhook, maps the provider user through an explicit tenant-owned binding, and runs that thread on the same durable agent runtime.

Ductor can also go the other way and import external MCP providers as connectors; that lives with the connector machinery under External MCP providers.

Every AI feature is off by default and fails closed

mcp.enabled, aichat.enabled, and ai_inference.enabled all default to false. Nothing here is reachable until you opt in. And the dependencies are enforced at startup, not lazily: aichat.enabled=true requires ai_inference.enabled=true with at least one provider, a Postgres pool, and a ready MCP backend — miss any of them and the process fails to start rather than serving a half-wired agent. Provider API keys are never read from config files; they come from environment variables named by each provider's api_key_env.

The shared spine

The reason these features belong in one section is that they are not independent integrations — they reuse each other:

Tenant agent Consumer MCPtenant-scoped tools Platform-admin agent Admin MCPproduct lifecycle Operator client Durable chat host(application/aichat) Workflow run(ai_agent step) Durable workflow host(application/workflow/dag) Slack thread Authenticated conversation bridge Shared agent runtimestate machine + bounds Append-only agent journalsequence + replay cursor Canonical tool registry +exposure manifests Admin registry +platform authorization Inference proxy(application/ai)provider-agnostic, OpenAI-compatible openai · anthropic · gemini · bedrock · ollama

The external MCP server and Ductor-hosted agents draw from the same canonical tool catalog and enforce the same explicit agent-session exposure policy. Chat and workflow hosts submit immutable turns to one journal-backed runtime rather than implementing separate LLM loops. Every provider call routes through the inference vertical, while committed events—not an open network connection—define progress.

What's in this section

MCP Admin & Consumer Servers

Isolated stateless MCP 2026-07-28 planes for tenant operation and governed platform lifecycle administration.

Agent Tool Security

The least-privilege exposure engine — explicit agent-session manifests, schema-hash binding, policies, redaction, and the decision receipts that authorize or deny every call.

Chat Agent

Admit a turn, consume committed SSE events, reconnect by sequence, and resume approval-gated tools without repeating provider work.

Durable Agent Runtime

The shared journal, state machine, immutable admission contract, recovery boundaries, execution bounds, and host adapters.

Durable Session Channels

Multi-turn identity, membership, ordered controls, resumable streams, verified snapshots, retention, and safe runtime upgrades.

Governed Agent Skills

Signed, content-addressed instruction bundles with progressive disclosure and broker-authorized read-only access.

Provider-Aware Prompt Caching

Stable tenant-bound cache identities, native provider hints, normalized usage, and cache-aware budget accounting.

Trusted-Edge Admission

Signed, expiring, replay-safe anti-abuse context for public chat admission.

Deterministic Agent Watches

Explicitly approved monitoring with registered evaluators, live reauthorization, and durable notification evidence.

External Conversation Bridges

Signed Slack ingress, explicit actor bindings, durable FIFO processing, same-thread replies, and encrypted single-use browser approvals.

Inference Proxy

The OpenAI-compatible, provider-agnostic router: RouteInference, health from live error rates, circuit breakers, and durable cost, latency, error, agent, workflow, and experiment attribution.

Experiments

Compare agent definitions and workflow steps with immutable exposure receipts and idempotent delayed scores.

Agent Presets

Two things called "preset": compile-time preset templates surfaced as connector actions, and tenant-owned versioned agent presets referenced by sessions.

Workflow AI Steps

Worker-side ai_action and durable ai_agent steps inside a DAG run.

External MCP Providers

The other direction — importing a third-party MCP server as a Ductor connector.