CorrelAct

CorrelAct is human-governed operational AI that investigates across systems, proposes actions, and executes only what a human explicitly approves.

Comment

CorrelAct

Human-led operational intelligence, built on WebMCP

Inspiration

Operational problems rarely live inside one system. A customer reports an issue through Support, the account context lives in CRM, and the root cause is buried in Billing. An AI agent can help connect those signals — but giving it permanent write access to operational systems creates a different problem: how do you let it act without giving it standing authority to make consequential changes?

CorrelAct started with a simple idea: let the agent investigate broadly, but make its authority to act narrow, explicit, and human-approved. It should gather evidence, correlate information, and recommend an action autonomously. But before it creates a task, changes a customer record, or performs any other consequential write, a human reviews exactly what is about to happen.

That became the core architecture of CorrelAct.

What it does

CorrelAct is a human-led operational intelligence platform that uses WebMCP to let a browser-native AI agent work directly across operational workspaces. The agent can:

  1. Read customer evidence from Support.
  2. Read account and renewal state from CRM.
  3. Read invoice and dispute evidence from Billing.
  4. Correlate those signals into one operational diagnosis.
  5. Submit a focused Proposed Action for human review.
  6. Wait for explicit human approval.
  7. Receive only the execution capability that was approved.
  8. Perform the approved consequential action through a protected backend.
  9. Leave a complete audit trail of the investigation, decision, execution, and outcome.

Read → Correlate → Propose → Human Approval → Exact Capability Exposed → Constrained Execution → Audited Outcome

The demo scenario

Our reference scenario involves ACME, a NorthStar customer whose renewal is blocked. The agent discovers evidence across three operational sources:

  • Support shows an escalated customer case reporting an incorrect invoice and blocked renewal.
  • CRM shows ACME's account and persisted renewal state.
  • Billing shows a disputed invoice with a variance and renewal hold.

The agent correlates those signals and submits a Proposed Action. At this point, nothing consequential has happened — the run enters AWAITING_APPROVAL, where a human reviewer can inspect the evidence, recommendation, customer, organization, and the exact execution capability being requested.

Only after approval does the run become APPROVED. Even then, approval does not execute the action — it authorizes the agent to perform one previously reviewed capability.

Dynamic Agent Authority

Most agent systems expose their write tools permanently and rely on the backend to reject inappropriate calls. CorrelAct narrows the capability surface earlier than that.

If there is no matching approved work, the consequential WebMCP tools — create_task and update_crm_status — simply are not registered for the agent on the Tasks workspace. After a human approves matching work, the appropriate tool becomes available. After that authority is consumed, the executable run disappears and the available tool set is recalculated.

The browser agent never holds permanent standing write authority. Authority appears because a human approved specific work — and disappears the moment that work is done.

Two governed write paths, one approval boundary

We deliberately implemented two different consequential actions to prove the governance model isn't a special case hardcoded around one integration.

create_task creates a real GitHub Issue using the scope that was already reviewed and approved. The execution call cannot rewrite the approved task content, priority, team, customer, or organization.

update_crm_status applies one approved CRM renewal-status transition — for example, blocked → escalation_open. The agent does not supply the target state at execution time; that transition is frozen inside the Proposed Action before human review. The execution tool receives only enough information to identify the approved run, organization, and evidence-bound customer.

Both capabilities pass through the same governance model:

Human Approval → Shared controlled-execution boundary (organization · customer · evidence · approval state · execution type · idempotency · audit) → either create_task → GitHub Issue or update_crm_status → CRM record

This mattered to us because we wanted to demonstrate that human-gated agent execution is a reusable architectural pattern, not a one-off built around a single API. Same governed boundary. Different consequential action.

WebMCP

WebMCP provides the capability surface connecting the browser agent to CorrelAct:

Tool Role
get_case Read Support evidence
get_customer Read CRM account and renewal state
get_invoice Read Billing evidence
submit_action_point Persist an evidence-grounded Proposed Action
create_task Execute an approved GitHub task
update_crm_status Execute an approved CRM status transition

The three evidence sources intentionally demonstrate different implementation patterns. Support and Billing use deterministic browser-local reference datasets — they make the cross-system WebMCP investigation reproducible without pretending to be production database integrations. CRM is application-backed through FastAPI and PostgreSQL. The consequential actions are application-backed too: create_task and update_crm_status each reach independently protected backend routes.

This distinction is intentional: browser-native WebMCP delivers the agent capability experience, while consequential authority stays server-enforced.

Security and trust model

CorrelAct assumes that browser-side restrictions alone are not sufficient protection for consequential actions — the backend independently re-checks every execution request. Enforced boundaries include:

  • authenticated session and organization access;
  • human approval state and the specific approved execution capability;
  • evidence-bound customer matching;
  • current CRM state for stateful mutations, so a stale approval can't silently overwrite newer data;
  • allow-listed CRM transitions, execution scope, and durable idempotency;
  • full audit persistence.

We tested these boundaries through automated tests and live browser-agent abuse scenarios: an approved action tied to one customer cannot be replayed against another customer; a run belonging to one organization cannot be executed against another; a CRM transition whose expected state has gone stale is rejected rather than silently overwritten. Approval itself never performs the external write.

Human visibility

Human control isn't hidden inside API responses. CorrelAct makes the progressive authority model visible across the product — the reviewer sees the exact execution capability and scope before approval, the Tasks workspace shows whether write authority is locked, available, or consumed, and Runs / Traces preserve the full lifecycle:

Agent Read → Agent Proposal → Human Decision → Agent Write → Outcome

This makes the governance model both enforceable and inspectable.

How we built it

  • WebMCP for browser-native agent capabilities
  • OpenAI-powered agent reasoning for operational investigation
  • FastAPI for the protected application and execution boundary
  • PostgreSQL for runs, evidence, organizations, CRM state, approvals, and execution records
  • GitHub Issues API as a real external write integration
  • JavaScript browser workspaces for Support, CRM, Billing, Investigation, Approvals, Tasks, Runs, and Traces
  • Docker for reproducible deployment
  • Azure Container Apps for the live deployment
  • GitHub Actions for security checks, automated tests, browser testing, evaluation, and deployment

The application also includes organization-scoped demo identities so isolation can be tested between NorthStar/ACME and Neptune/GreenMart.

Challenges we ran into

Separating approval from execution. A deceptively important architectural decision was ensuring that clicking Approve did not perform the action. Approval had to mean "this exact capability and scope may now be executed," not "execute this immediately." Keeping those phases separate made the system significantly easier to reason about and audit.

Preventing approved scope from drifting. We didn't want the agent to receive approval for one action and then change its parameters at execution time. For CRM writes, the exact expected and target statuses are frozen before approval. For task creation, task content comes from the approved Proposed Action rather than a new free-form execution payload.

Making authority visible. Backend authorization alone wasn't enough for the experience we wanted — we wanted the agent's available tool set itself to reflect current human authorization. That led to Dynamic Agent Authority: controlled execution tools are registered and removed based on currently approved, executable work.

Idempotency. Agent actions can be retried, so a consequential write can't rely on the assumption that a tool will only be called once. CorrelAct uses durable execution records and locking so repeated or retried execution cannot silently create duplicate consequential outcomes.

Testing adversarial cases. The happy path was only part of the work. We deliberately tested incorrect customer names, organization mismatches, unapproved execution, wrong execution capabilities, repeated execution, stale CRM state, and organization isolation. Those tests shaped the architecture as much as the successful demo flow did.

What we're proud of

The strongest part of CorrelAct is not that an AI agent can call a tool — it's the boundary around when that tool should exist and what it should be allowed to do. CorrelAct demonstrates autonomous multi-source investigation, evidence-grounded recommendations, explicit human review, approval without automatic execution, dynamically exposed agent authority, exact capability binding, two differently-shaped governed write operations, backend-enforced organization and customer scope, durable idempotency, persisted operational state, and a complete audit trail.

The agent is useful before approval without being powerful after approval in ways the human did not authorize.

What we learned

Building CorrelAct reinforced that human-in-the-loop AI is not simply about adding an approval button — the approval must correspond to a real technical authority boundary. If an agent still has broad permanent write access after the user reviews a recommendation, the human interaction is mostly ceremonial.

A stronger pattern is:

Evidence determines the proposal. The proposal determines the scope. The human determines whether that scope becomes authority. The backend determines whether the authority is valid.

WebMCP made it possible to make that progression visible directly in the browser-agent experience.

What's next

CorrelAct currently demonstrates the governance model with two controlled writes: GitHub task creation and CRM status mutation. The same architecture extends naturally to other operational capabilities — ticketing systems, finance workflows, customer-success actions, ERP operations, internal approvals, and incident-management systems.

The long-term direction isn't to give agents unrestricted access to more systems. It's to make more operational capabilities available under precise, contextual, human-controlled authority.

Core idea

Investigate broadly. Approve explicitly. Execute narrowly. Audit everything.

Same governed boundary. Different consequential action. The agent receives only the capability the human approved.

Built With

Share this project:

Updates

Submission history