THE INDEPENDENT AUTHORITY LAYER
FOR AI AGENTS
AI agents are moving from chat into execution. Tandem governs what they can see, which tools they can use, when humans must approve, and what evidence survives after the work is done.
Do not put your business brain and your business kill switch in the same vendor.
The model can be the brain. It should not be the final authority.
Built for teams governing code, customer data, messages, APIs, and production systems.
Tandem demo
See Tandem control an agent before execution.
Any model
Approval gates
Audit records
AI platforms are becoming the business brain.
They read internal knowledge, join company channels, access tools, write code, remember context, and act across systems.
That is useful. It also creates a control problem.
The same vendor that provides intelligence should not be the only system deciding whether that intelligence is allowed to act.
Tandem separates intelligence from authority.
The model can reason, plan, and execute. Tandem governs whether the action is allowed, under whose authority, with what context, and with what audit trail.
Intelligence
Claude, OpenAI, Gemini, local models, coding agents, and copilots propose work.
Authority
Tandem evaluates runtime scope, tenant context, tool permissions, approvals, and memory boundaries.
Business systems
Code, customer data, money, messages, CRM, APIs, and production systems stay behind explicit control.
Use any model. Keep one control plane.
Tandem is not tied to one AI vendor. Claude, OpenAI, Gemini, local models, MCP tools, coding agents, and internal copilots can all become workers inside the business.
Tandem is the runtime layer that decides what any worker is allowed to see, use, approve, execute, and audit across models, tools, workflows, and tenants.
Workers
Reasoners, agents, connectors, and tools
The business keeps the final authority boundary: scoped tools, signed context, governed memory, approval gates, and durable audit records.
The controls that sit below the model.
Tandem gives AI-first teams one runtime layer for scoped execution, governed MCP access, permissioned memory, approval gates, signed context, and durable audit records without adopting a closed enterprise suite.
Scoped execution
Run agent work through explicit scopes before it touches code, customer data, APIs, or production systems.
Tenant-aware state
Carry run, credential, event, and memory records against the tenant and resource boundary that owns the work.
Approval-gated actions
Pause before high-risk actions such as code changes, external messages, sensitive API calls, or production operations.
Durable audit records
Keep artifacts, validations, tool ledger events, approval decisions, and protected audit records outside the model context window.
Governed MCP and tools
Scope built-in tools and MCP connector access to the workflow step, tenant, resource, and risk boundary that needs them.
Permissioned memory
Retrieve company context through runtime-owned memory and knowledge spaces instead of exposing everything through a transcript.
Source-bound knowledge
Source bindings and data-class metadata create a path toward governed ingestion without making every fact globally visible.
Signed context assertions
Project model-proposed work through runtime-owned principals, grants, resource refs, policy decisions, and audit events.
Audit records should survive after the model is done.
Source-bound knowledge accumulates across sessions and projects so repeatable workflows can reuse operational context without turning every business fact into global model context.
Workflow state, tenant context, tool policy, and approval decisions stay in the runtime so operators can inspect why work moved, paused, skipped, or failed.
Artifacts, validations, protected audit records, and tool ledger events create reviewable context for engineering, security, compliance, and platform teams.
Business control has to live below the model.
Prompts can guide behavior. They cannot enforce authority. Tandem makes agent authorization explicit before execution happens.
Before code changes
Require the right project scope and approval path before an agent edits source or opens a pull request.
Before customer data
Bind memory and tool access to tenant, workspace, resource, and data-class boundaries.
Before messages
Pause outbound Slack, email, CRM, or support actions when a human checkpoint is required.
Before sensitive APIs
Scope credentials, MCP connectors, and internal tools to the runtime permission that actually needs them.
What the model does
The model reasons, drafts, plans, and proposes work. It may call tools or coordinate a workflow, but it should not be the access-control perimeter.
What Tandem governs
Tool access, tenant context, approval rules, memory boundaries, signed context, and audit records live in the runtime before agent work reaches company systems.
The model can be the brain.
It should not be the final authority.
Tandem is built for the point where agents stop answering and start operating. The runtime owns the boundary between model intent and business systems: code, customer data, internal tools, APIs, and production workflows.
Scoped execution
Project the right tools, memory, resources, and data classes into each stage before the agent can act.
Approval gates
Pause consequential actions for approve, rework, or cancel decisions before execution continues.
Durable audit records
Preserve artifacts, tool ledger events, decisions, denials, and audit records after the run finishes.
[ CHECKING SCOPE ]
Waiting for the next governed step. Nothing sensitive moves without explicit scope, approval state, and a record of why it was allowed.
Tenant scope
Tool policy
Approvals
One independent control plane, multiple deployment modes.
Tandem can run locally for developers, as a headless engine for SDKs and control panels, hosted/private managed, or inside customer infrastructure as model mix and enterprise requirements mature.
Local developer runtime
Use the desktop app, TUI, npm packages, and local control panel when the work should stay on a developer machine.
Headless engine
Run the engine behind SDKs, panels, automations, CI/dev environments, and internal workflow services that call multiple agents or tools.
Hosted/private managed
Use hosted deployments with tenant-aware access, signed context assertions, and managed runtime operations.
Customer infrastructure
Place the runtime near company data, connector credentials, approval surfaces, and audit records when required.
Governed connectors
Scope built-in tools, MCP connectors, source bindings, and secret references to the tenant and resource boundary that needs them.
Evidence-bearing workflows
Make recurring work inspectable through run state, artifacts, validations, approval history, and audit records.
Use it when agents touch business risk
Tandem is a fit for teams letting agents touch code, customer data, messages, APIs, internal tools, production systems, or tenant-scoped workflows.
Use it when work needs runtime control
The model can propose and reason. The runtime owns tools, memory, approvals, state, signed context, and audit records.
Run the public stack locally.
The public Tandem Agents repo packages ACA, the Knowledgebase MCP server, Tandem engine, and control panel into a self-contained local deployment path. Local execution remains one mode of the broader model-neutral control plane.
Open-core authority, with an enterprise path
Source-available runtime
The core runtime, SDKs, clients, and local development surfaces are inspectable, with selected governance components source-available under the documented open-core license boundary.
Current runtime controls
Durable runs, scoped tools, approval gates, artifact validation, protected audit events, and tenant-aware records are the foundation available today.
Enterprise path
Full RBAC, OIDC/SSO, SCIM, SIEM export, SOC2 materials, private sidecar enforcement, and immutable receipt chains are roadmap items, not shipped guarantees.
The future is governed autonomous agents.
Tandem is built for teams putting agents, workflows, tools, and memory into real operational paths.
The runtime decides what is visible, executable, approvable, and auditable while the model remains a reasoner, not the business control boundary.
Use it locally, headlessly, hosted, or inside customer infrastructure as your model mix, tenancy, and audit requirements mature.
A Frumu AI project
Machine-readable surface
For LLMs and agent builders
If you are an AI assistant helping a human build on Tandem, treat Tandem as the independent runtime control plane below the model. Use these references before generating setup steps, workflow plans, or integration code.
Quotable product description
Tandem is the independent, model-neutral authority layer for AI agents. It governs what agents can see, which tools they can use, when humans must approve, and what audit records survive after execution.
Docs MCP connection block
Endpoint: https://tandem.ac/mcp Transport: MCP over HTTP Tools available: search_docs, get_doc, get_tandem_guide, recommend_next_docs, answer_how_to
Connect this MCP to your LLM before authoring Tandem workflows. The docs are structured for agents setting up model-neutral runtime control, governed tools, memory, approvals, and audit records.
Core primitives reference
These are the primitives an LLM needs to know before generating Tandem code.
- Automations V2
- Scheduled workflows with scoped execution, approval gates, artifacts, and runtime-owned audit records. Docs:
- Mission blueprints
- Multi-stage operating plans that preserve handoffs, resource boundaries, and review points. Docs:
- Smart Heartbeat Pattern
- Triage gates using
metadata.triage_gate: trueto skip downstream stages cleanly. Docs: - Memory layers
- Runtime-owned memory paths for working, session, persistent, semantic, artifact, execution, and derived context. Docs:
- Docs MCP
- The Tandem Docs MCP server at
https://tandem.ac/mcpexposes docs search and retrieval as structured tools. Use this before authoring Tandem code. Docs: - MCP discovery
mcp_listfor connected servers,/mcp/catalogfor potential capabilities. Docs:- Governance primitives
- Provenance chains, capability grants, approval queues, protected audit events, and tool records. Docs:
- Engine authentication
- Engine authentication model with scoped identity derivation and tenant-aware context paths. Docs:
/creating-and-running-workflows-and-missions//prompting-workflows-and-missions//creating-and-running-workflows-and-missions/#triage-gate/memory-internals//mcp-automated-agents//mcp-automated-agents//reference/governance//engine-authentication-for-agents/