AuraBot CI Workbench

Why this is an orchestration problem, not a chatbot problem

A competitive intelligence workflow touches four distinct jobs: collecting public signals, normalizing raw findings into a comparable structure, translating findings into GTM implications, and delivering a traceable weekly report that survives audit. A flat chat interface handles none of these reliably — there is no repeatability, no approval gate, no cost record, and no artifact that a downstream stakeholder can act on.

AuraBoot's answer is the AuraBot workbench: missions, tasks, agent definitions, approval policies, schedules, and artifact surfaces that compose into a governed agent scenario. The CI use case is the first packaged scenario, but the workbench structure is generic enough to host any multi-agent enterprise workflow on the same runtime.

Data model summary

The CI workbench is backed by eight cooperating objects:

• ci_target_company — Watched competitor; carries scope, priority tier, and preferred source types.
• ci_signal — Individual raw finding (product, pricing, hiring, customer, or public social); states raw → tagged → enriched → archived.
• ci_signal_tag — Controlled vocabulary tag applied to a signal; links signal to target company and theme.
• ci_briefing — Weekly intelligence report aggregating enriched signals; states draft → review → published → archived.
• ci_briefing_section — Structured section within a briefing (overview, product changes, pricing, GTM implications, battlecard notes).
• agent_memory — Tenant or user preferences: priority competitors, preferred output format, risk tolerance, source keywords.
• agent_artifact — Persisted report artifact linked to an agent run; carries quality score and source-link evidence.
• approval_policy — Governs which agent actions require human confirmation (external web access, budget overrun, email delivery).

Objects belong to the aurabot module. Mission, task, run, trace, schedule, and interrupt surfaces are platform-level objects shared across all AuraBot scenarios.

Key commands

A button labeled "Publish briefing" wires to ci_briefing.publish — not to a raw PUT endpoint. The same command is reachable from automation rules ("auto-publish when all sections are approved"), from an AuraBot supervisor agent acting on behalf of the strategy lead, and from the approval queue after human sign-off. Each call declares riskLevel: write, idempotent: true so the agent runtime knows it is safe to retry without side effects.

Permission example

A realistic CI role: "Sales Enablement Lead".

• RBAC: granted ci.signal.read, ci.signal.tag, ci.briefing.read, ci.briefing.request_review; not granted ci.briefing.publish (held by Strategy Director) or aurabot.policy.manage (held by Admin).
• Org scope: data visibility limited to briefings and signals owned by their business unit (data scope = org-and-descendants).
• ReBAC: can request review on briefings they authored; cannot approve their own review requests (separation of duties — approval must come from a different user).
• ABAC: can tag signals with GTM themes only when signal_type ≠ pricing; pricing signals require Revenue Operations co-tag.
• Field-level: sees competitor pricing fields in signal detail (masked for junior researchers); cost-per-run fields in artifact detail are masked below Strategy Director.

All five layers are evaluated in order. A single declarative role configuration replaces hand-coded branching across the UI, controllers, and export reports.

Process orchestration

The weekly scan is a mission-driven flow. Each task is bound to an agent and a command:

  ┌──────────────────────────────┐
  │ Weekly schedule triggers     │  ←  agent_schedule (Monday 08:00)
  └──────────────┬───────────────┘
                 │
  ┌──────────────▼───────────────┐
  │ Research Agent               │  ←  collect signals from public sources
  │   ci_signal.create (batch)   │     website / pricing / release / jobs
  └──────────────┬───────────────┘
                 │
  ┌──────────────▼───────────────┐
  │ Data Analyst Agent           │  ←  ci_signal.tag + ci_signal.enrich
  │   normalize + compare table  │     produces structured diff vs prior week
  └──────────────┬───────────────┘
                 │
  ┌──────────────▼───────────────┐
  │ Approval gate (if needed)    │  ←  approval_policy: external access /
  │   human confirm or skip      │     budget overrun / email delivery
  └──────────────┬───────────────┘
                 │
  ┌──────────────▼───────────────┐
  │ Sales Agent                  │  ←  ci_briefing.create + section fill
  │   GTM implications           │     battlecard notes + talking points
  └──────────────┬───────────────┘
                 │
  ┌──────────────▼───────────────┐
  │ AuraBot supervisor           │  ←  ci_briefing.request_review
  │   quality rubric check       │     min length / sections / source links
  └──────────────┬───────────────┘
                 │
  ┌──────────────▼───────────────┐
  │ Strategy Director review     │  ←  ci_briefing.publish
  │   agent_artifact persisted   │     run id + quality score + trace link
  └──────────────────────────────┘

High-risk or externally visible actions pause the run and surface a pending approval entry on the dashboard. The AuraBot supervisor retains memory of prior week's preferences — priority competitors, preferred output format, source keywords — and carries them into each new run without requiring re-configuration.

Agent integration

Three command classes are intentionally exposed to agents in this solution:

1. Read-and-summarize (ci_signal.list_recent, ci_briefing.summary) — read-only, idempotent, zero risk. Research and Analyst agents call freely.
2. Drafting commands (ci_signal.create, ci_briefing.create, section fill) — write, idempotent, reversible. Agents draft; humans review through the existing request_review StateTransition.
3. Nudge commands (ci_signal.tag, ci_signal.enrich) — write, idempotent. Agent applies controlled vocabulary and source enrichment; cannot publish or deliver.

What is not exposed: ci_briefing.publish (externally visible delivery), approval_policy.update (governance surface), and any email or webhook delivery command. These carry agentHint: "Human-only" in their definitions; the platform's agent surface excludes them automatically.

How to get it

• Community: build it yourself. The AuraBot runtime, command pipeline, approval policy engine, and artifact surface are all open-source; the CI-specific models and agent definitions are not bundled.
• Standard: white-label the base platform; configure your own CI-shaped models and agent mission templates on top.
• Professional: get the CI Workbench solution — pre-wired models, agent definitions, approval policies, memory templates, and dashboard scenario panel.
• Enterprise: same package plus dedicated delivery engineering, SSO and data-residency review, and SLA-backed support.

See Pricing for the full edition comparison.

Enterprise note — Multi-tenant Agent Control Plane (run isolation per business unit), Observability Pro per-stage trace spans, Marketplace publication of packaged agent scenario templates, and License/Entitlement enforcement on the approval policy engine are commercial-only capabilities. The open-core AuraBot runtime, command pipeline, and workbench structure described above are the same in every edition.

Next steps

• System overview — how plugins, commands, and the runtime fit together
• Command pipeline — the execution contract used by every command above
• Permissions — the five-layer model used by the Sales Enablement Lead role
• Agent readiness — designing agentHint and risk fields for safe execution
• AuraBot overview — missions, tasks, runs, traces, approvals, and artifacts explained