Skip to main content
The Agent Surface is the umbrella term for everything Mission Control exposes around AI-driven workflows: the Automations engine (triggers + actions), the Agent Builder (custom LangGraph agents), the Skills library (composable prompt+tool blocks), the Knowledge Bases (RAG storage with cosine kNN retrieval), and the Live Operations dashboard + Run History that surface what’s running and what just ran. These are gated as a single surface — superusers and elevated agency roles can access all of them; client-tenant users see none of them. See Permissions for the full access matrix.

What’s in the surface

Automations

Trigger → conditions → action chains. 15 triggers (note lifecycle, schedule, agent runs, creative.hook_exhausted, …) and 15 actions (Slack, Notes, KB writes, run an agent, webhooks).

Agent Builder

Define custom LangGraph agents with their own system prompts, tool sets, and avatars. Agents live alongside Houston / Space Bob / Social Sally in the multi-agent swarm.

Skills

Reusable, composable prompt + tool bundles. Agents pull skills in as building blocks (e.g., “summarize a campaign”, “explain a creative”).

Knowledge Bases

Per-account RAG stores. Documents are chunked, embedded into pgvector, and retrieved via cosine kNN. Includes a Google Drive ingestion path.

Live Operations

Real-time dashboard of running automation runs, agent runs, and worker health. WebSocket-pushed via the automations consumer.

Run History

Paginated, filterable history of every automation run (success / failure / replay). Each row links to the input payload, the action chain, and the resulting log lines.

How the pieces fit

Triggers

15 triggers ship in automations/triggers/__init__.py. Each registers a payload schema that downstream actions can reference. Each trigger key has a config_schema (the form fields the UI shows) and a payload shape (the keys the trigger emits when it fires). The dispatcher passes the payload to actions verbatim — actions reference {{ payload.something }} in their templates.

Actions

15 actions ship in automations/actions/. Each is decorated with @register_action(...). run_agent is the action that bridges the automation engine into the agent swarm. Pair it with the agent.run_succeeded / agent.run_failed triggers to build retry / fallback / Slack-on-failure chains.

Engine

automations/engine.py is the single entry point:
dispatch(trigger_key, payload) finds matching automation rules for the tenant, evaluates each rule’s filters / payload_match conditions, and enqueues the action chain on the automations_standard Celery queue. Every step writes a row in automations.AutomationRun for the Run History view.

Live Operations + Run History

  • Live Operations is at /automations/operations. WebSocket consumer (automations/consumers.py) pushes events: run started, action completed, run failed. The dashboard shows in-flight automation runs alongside in-flight agent runs.
  • Run History is at /automations/history. Server-side paginated, filterable by trigger, action, status, date range, client. Each row deep-links to the run detail (input payload + action chain + per-step logs).
The agent.run_failed trigger fires automatically on any errored swarm run, so you can wire a Slack alert to surface failures back to the team.

API + WebSocket reference

All endpoints are gated by shared.permissions.AgentSurfaceAllowed (mirrors shared.auth.agent_surface_allowed).

Where the code lives