AI Agent Platform

Why this is a runtime problem, not a chatbot problem

Enterprises that bolt a chatbot onto a business application get a conversational wrapper around a database. The AI can answer questions about data it was trained on, but it cannot act on live records, enforce permissions, respect approval chains, or coordinate with other agents across a workflow.

The Agent Control Plane (ACP) takes the opposite approach. Every AI action is a command — the same permissioned, audited, event-emitting unit that a human pressing a button would invoke. An agent that drafts a sales quote goes through acp:create_mission, resolves its tools against the registered tool registry, invokes sales_order.draft through the command pipeline, and emits an agent_action record. If the action crosses a risk threshold, an agent_approval request is generated before execution resumes. Nothing bypasses the runtime.

Data model summary

ACP ships as two cooperating plugins (agent-control-plane and ai-employees) defining 16 models across four layers:

• agt_agent_definition — Agent configuration: type (autonomous / copilot / reactive), assigned model, tool list, soul profile (personality, expertise, boundaries).
• agt_mission — High-level business objective; states active → paused → completed → archived.
• agt_task — Individual unit of work assigned to an agent or human; states backlog → todo → in_progress → done / blocked / cancelled.
• agt_run — Execution record capturing input_tokens, output_tokens, total_cost, duration_ms, and final status.
• agt_artifact — Outputs produced by a run (documents, reports, code, data, emails).
• agt_approval_policy — Rules that trigger human review: by risk level, action type, cost threshold, or time window.
• agt_agent_approval — Pending approval request; resolves to approved / rejected / expired.
• agt_agent_action — Immutable audit record of every tool call an agent made.
• agt_agent_memory — Persistent per-agent knowledge in six types: fact, preference, lesson, context, decision, summary.
• agt_agent_tool — Tool definitions (DSL command, DSL query, custom API, MCP server, LLM native) with risk classification.
• agt_agent_skill — Reusable skill packages at three levels: atomic, workflow, solution.
• agt_agent_schedule — Cron, interval, event-triggered, and one-time execution schedules.
• agt_mcp_server — Registry of external MCP-compatible tool servers.

Key commands

ACP defines roughly 40 commands. Five representative ones show the three shapes:

The same command declaration that governs human UI buttons governs agent invocations. An agent calling acp:invoke_skill with skill_code: "query_orders" goes through the identical permission check, audit log, and event emission as a sales rep clicking the same button.

Permission example

A realistic ACP role: "Operations Lead — APAC".

• RBAC: granted acp.mission.create, acp.task.manage, acp.run.view, acp.agent_tool.read; not granted acp.approval_policy.manage (held by Compliance Admin) or acp.agent_definition.delete.
• Org scope: data visibility limited to the APAC org subtree (org-and-descendants); cannot see missions or runs belonging to EMEA teams.
• ABAC: can approve data_change approval requests only when risk_level is low or medium; high and critical escalate to the Security Officer automatically.
• ReBAC: can resolve approval requests for agents they supervise; cannot approve their own agent's requests (separation of duties enforced at the policy layer).

All four layers are evaluated in order on each command invocation. A single declarative role configuration handles what would otherwise be scattered across UI guards, controller annotations, and report filters.

Process orchestration

A mission flows through ACP as a directed task graph. Each node is either an agent task (executed by a registered agent) or a human task (routed to an approval queue):

  ┌──────────────────────────────┐
  │  Mission created             │  ←  acp:create_mission
  └──────────────┬───────────────┘
                 │
  ┌──────────────▼───────────────┐
  │  Agent: gather context       │  ←  agt_run (tool: dsl_query)
  └──────────────┬───────────────┘
                 │
  ┌──────────────▼───────────────┐
  │  Agent: draft recommendation │  ←  agt_run (tool: dsl_command, risk: medium)
  └──────────────┬───────────────┘
                 │
  ┌──────────────▼───────────────┐
  │  Approval gate (human)       │  ←  agt_agent_approval (triggered by policy)
  └──────┬───────────────┬───────┘
         │ approved       │ rejected
  ┌──────▼──────┐   ┌─────▼──────────┐
  │ Agent: act  │   │ Task: cancelled │
  └──────┬──────┘   └────────────────┘
         │
  ┌──────▼──────────────────────┐
  │  Mission completed          │  ←  agt_artifact produced
  └─────────────────────────────┘

Missions can be scheduled (agt_agent_schedule) or triggered by platform events. A reactive agent monitoring an IoT stream can open a new mission automatically when an anomaly threshold is crossed, decompose it into investigation tasks, and escalate to a human operator only if the anomaly score exceeds a configured level.

Agent integration

Four tool classes are intentionally surfaced to agents, differentiated by risk:

1. Read-only DSL queries (dsl_query, risk: low) — agents call freely; no approval needed. Example: query_active_missions, list_agent_runs.
2. Idempotent write commands (dsl_command, risk: medium) — agent drafts or creates; approval policy determines whether a human reviews before commit.
3. External integrations (mcp_server, custom_api, risk: high) — always routed through an approval gate; timeout_action controls auto-behavior if reviewers are unavailable.
4. AI Employee tools (llm_native) — built-in capabilities like platform_execute_sql; risk determined by the query scope declared in the tool registration.

What is not exposed to agents without explicit opt-in: any command with agentHint: "Human-only", risk_level: critical, or commands flagged irreversible (acp.agent_definition.delete, policy deletion). The platform's agent surface enforcer filters these at tool-registration time, not at runtime.

The pre-built AI Employees (AuraBot coordinator, Dex data analyst, Sage business analyst, Aria writing assistant) participate in group chat. Each responds to @mention with access to only the tools declared in their definition. AuraBot's transfer_to_agent tool lets it delegate specialized sub-tasks to Dex or Sage without exposing those agents' full tool surface to the original chat participant.

How to get it

• Community: the ACP plugin architecture, command pipeline, and permission model are open-source. Build custom agent definitions and skill packages on top of the runtime.
• Standard: white-label the base platform; configure agents, tools, and approval policies through Page Designer without writing code.
• Professional: get the full ACP plugin bundle — pre-wired menus, AI Employee seed data, approval policy templates, and observability dashboards.
• Enterprise: same bundle plus dedicated delivery engineering, multi-tenant agent governance, and SLA-backed support.

See Pricing for the full edition comparison.

Enterprise note — Cross-tenant Agent Control Plane (running agents across multiple tenant instances with shared mission oversight), Observability Pro per-run trace spans, Marketplace publication of packaged skill libraries, and License/Entitlement enforcement on the tool registry are commercial-only capabilities. The open-core runtime, command pipeline, and permission model described above are identical in every edition.

Next steps

• System overview — how plugins, commands, and the runtime fit together
• Command pipeline — the execution contract every agent tool invocation follows
• Permissions — the multi-layer model used by the Operations Lead role above
• Plugin manifest — how ACP plugin dependencies are declared and resolved
• Agent readiness — designing agentHint, riskLevel, and idempotent fields for safe agent execution