AgentNexusAPI — Product & Market Report

Purpose: A factual, implementation-grounded overview for marketing materials, investor or buyer conversations, and internal value assessment. This document describes what the application does today, how it works, which organizational problems it addresses, and why that matters commercially.

Product positioning (one line): AgentNexusAPI is a runtime governance layer for AI agents and autonomous workflows: it evaluates every material request against policy, routes human approval by role, records outcomes in an audit trail, and supports closing the loop with execution receipts after downstream work completes.

1. Executive summary

Organizations are moving AI agents from experiments into production systems that touch money, regulated data, and customer trust. Informal approvals (chat, email threads, one-off scripts) fail basic enterprise expectations: separation of duties, consistent rules, provable history, and tenant isolation.

AgentNexusAPI provides:

A single integration contract (POST /api/v1/evaluate) so engineers do not rebuild auth, routing, and logging for every agent.
A policy engine (JSON rulesets) that can auto-approve, reject, require one approver, or require ordered multi-stage approval with optional email OTP on sensitive stages.
Workspace-scoped RBAC (admin, developer, approver) so the people who write rules, integrate systems, and sign off are not the same by default.
Key-bound tenancy: the API key determines the workspace; clients do not send workspace IDs on evaluate, reducing cross-tenant mistakes and spoofing.
A hosted approval experience (magic links) that shows exactly what payload is being authorized.
Audit visibility in the dashboard and POST /api/v1/receipt to attach execution outcomes after an approved action runs.

The result is a defensible control point between “agent wants to act” and “action is allowed to proceed”—with evidence suitable for security, compliance, and operational review.

2. What has been built (feature inventory)

The following reflects the current codebase (Next.js App Router, Supabase Postgres + Auth), suitable for production-style deployment (e.g. Netlify + Supabase).

2.1 Core API

Public surface summary: /openapi.yaml (static; set servers to your deployment URL).

Capability	Description
`POST /api/v1/evaluate`	Validates body (`policy_name`, `context.agent_id`, `context.payload_scope`, optional `webhook_url`). Optional `Idempotency-Key` header (per workspace) for safe retries. Resolves workspace from API key hash. Loads latest `policy_versions` snapshot by policy name, runs ruleset engine, creates an evaluation row with `policy_version_id`, creates approval stages when human gates apply, notifies approvers (email via Resend), writes audit events, and when `webhook_url` is set can call the integrator webhook for approval required and terminal outcomes.
`POST /api/v1/receipt`	Accepts execution proof after downstream work (e.g. transfer completed, ticket closed). Tied to the same API key / workspace rules; eligible when evaluation is approved or auto-approved. Closes the “proposal → decision → execution” loop in the database.
`POST /api/mcp`	MCP (Model Context Protocol) JSON-RPC gateway: `initialize`, `tools/list`, `tools/call` for evaluate and get evaluation; same API key as REST. Writes `mcp_trace` into `context_json` and `run_bundle` for agent-execution lineage (MCP_GATEWAY.md). Cursor / Claude sample configs and a stdio→HTTP bridge ship in `integrations/mcp-stdio-bridge/`.
Approval APIs	`approve`, `reject`, `request-otp`, `verify-otp` under `/api/approval/[token]/…` for the hosted UI and magic-link flows.

2.2 Policy engine

Conditions on dot-path fields in payload_scope (e.g. amount, metadata.region) with operators such as equality, ordering, and list membership.
Actions with priority and first matching wins semantics: auto_approve, reject, require_approval, multi_stage.
Routing stages with stage_index, role (aligned to workspace RBAC), and tier (standard magic link vs critical_otp), plus optional time-boxed windows (approval_timeout_seconds, on_approval_timeout: auto-reject or escalate to the next stage; enforced by cron — see APPROVAL_TIMEOUTS.md).
Templates in the dashboard: single-stage (every request / high-amount only), auto-approve all, multi-stage approver → admin, multi-stage with OTP final admin stage, 48h auto-reject, 24h escalate to admin; custom JSON for advanced cases.
Client-side validation (Zod) so invalid rulesets cannot be saved from the UI.
Policy-as-Code (GitHub): optional per-policy link to a repo path; signed webhooks on push update ruleset_json (and append policy_versions). Manual sync and optional PAT for private repos (POLICY_AS_CODE_GIT.md).

2.3 Tenancy, identity, and security model

Workspaces as the unit of isolation for policies, keys, members, evaluations, and audit.
Workspace lifecycle: archive / restore / admin-only permanent delete (with confirmation), supporting operational hygiene without pretending deletes are “instant magic.”
API keys: hashed at rest; workspace derived from key; revocation supported.
Service role used only on the server for evaluate/approval paths where RLS must be bypassed safely—never exposed to browsers.

2.4 Human approval UX

/approve/[token] page: shows policy name, current stage (index, role, tier), optional decision deadline when the policy defines a timeout window, multi-stage pipeline progress, payload scope as structured JSON, OTP flow for critical tiers, approve/reject actions.
Email notifications to all members of the workspace matching the required role for the active stage (not named individuals in the policy file—roles are the contract).

2.5 Dashboard (authenticated product UI)

Overview with product narrative, state-aware “next step”, and setup checklist driven by live data.
Workspaces, Policies (create/edit with templates, advanced JSON, routing preview, GitHub ruleset sync for admins), Team (invite, roles), API Keys, Audit log (evaluations list + detail with approval pipeline visualization), Governance analytics (workspace-scoped approval rates, human decision time, rejection reasons over selectable periods), Cost attribution (workspace default and per-agent_id override in cents per evaluate, snapshotted on evaluations.attributed_cost_cents, dashboard rollups; see COST_ATTRIBUTION.md), Compliance reports (one-click ZIP with Markdown narrative mapped to SOC 2 / ISO 27001 / EU AI Act Art. 14 themes plus capped CSV extracts of evaluations, audit events, and approval stages).
Loading / pending states on submits across key flows (policies, workspace actions, invites, sign-out, API key generation).
Landing page for signed-out visitors: value prop, how it works, capabilities, audiences, CTAs.

2.5a Sign-in (public)

Email + password (Supabase Auth) on /login and /signup.
Enterprise SAML SSO (Okta, Entra ID, etc.) via Supabase signInWithSSO when NEXT_PUBLIC_AUTH_ENTERPRISE_SSO is enabled; work-email/domain routing or optional fixed NEXT_PUBLIC_SSO_PROVIDER_ID.
OIDC / OAuth (e.g. Microsoft azure, Google google) via optional env NEXT_PUBLIC_AUTH_OIDC_PROVIDERS and Dashboard provider configuration.
Callback: /auth/callback exchanges the auth code for a session; errors redirect to /login with a message.

2.6 Data & audit

Evaluations record status (e.g. auto-approved, pending human, rejected, approved).
Approval stages track per-stage state, tokens, OTP fields, and ordering.
Audit log events for evaluation and approval milestones (extensible pattern for compliance narratives).

3. How it works (end-to-end flows)

3.1 Happy path — auto-approve

Integrator calls /api/v1/evaluate with a policy name and payload_scope.
Engine matches an auto_approve action.
Evaluation is stored as auto-approved; webhook may fire (per implementation). Receipt can still be posted if you treat auto-approved actions as needing proof of execution.

3.2 Happy path — human approval (single stage)

Evaluate matches require_approval with one routing stage (e.g. role approver, tier standard).
System inserts approval_stages, puts a token on the current pending stage, emails eligible members.
Approver opens magic link, reviews payload_scope, approves or rejects.
On approve, if no pending stages remain, evaluation moves to approved; /api/v1/receipt can record what actually ran.

3.3 Multi-stage path

Evaluate matches multi_stage with two or more routing_stage_indexes (e.g. approver then admin).
Stages are created in order; only the lowest pending stage has an active token and notification batch.
After stage 1 approves, the system notifies the next role for stage 2 (and enables OTP if that stage uses critical_otp).
Dashboard policy editor and approval / audit UIs show a pipeline so users always see where they are in the chain.

3.4 Why the API shape is intentional

policy_name ties runtime traffic to a named ruleset under a workspace—good for versioning and clarity (“payments-default” vs opaque IDs in logs).
payload_scope is the contract for rules: anything the policy references must be present here—reduces “magic context” and helps auditors.
No workspace_id in the evaluate body enforces key-bound tenancy: compromise of one key does not grant parameterizable access to other tenants.

4. Problems it solves (customer pain → product answer)

Problem	Consequence today	How AgentNexusAPI addresses it
Ad-hoc approvals (Slack, email, tribal knowledge)	Inconsistent rules; no single source of truth; hard to prove who approved what	Policy + stages + audit; approvals go through defined roles and logged evaluations
Rules embedded in agent code	Every service reinvents thresholds; changes require deploys; drift between teams	Central rulesets evaluated on one API; change policy without redeploying every agent (within your release process)
Weak separation of duties	Same people code, operate, and approve high-risk actions	Workspace RBAC: developers integrate; approvers decide; admins govern configuration
Cross-tenant risk	Accidental or malicious wrong `tenant_id` in requests	Workspace from API key, not from caller-supplied workspace identifiers on evaluate
No evidence chain	“We thought the agent was allowed to do X” is not audit-ready	Evaluation + stages + optional receipt links proposal, decision, and execution outcome
Multi-party sign-off	Sequential approvals devolve to forwarding threads	Multi-stage routing with ordered stages and role-based notifications
High-risk sign-off	A single leaked link approves anything	`critical_otp` tier adds email OTP before approve on designated stages

5. Why this is valuable and “enterprise-grade”

5.1 Value for engineering organizations

Integration surface is small: one primary ingress (evaluate) plus receipt—teams ship faster than building an internal policy platform.
Operational clarity: dashboard, audit log, and approval UI reduce “what happened to this agent run?” tickets.

5.2 Value for security, risk, and compliance stakeholders

Governance is explicit (policy JSON / templates), not buried in application code.
Human decisions are tied to roles and stages, supporting segregation of duties narratives.
Immutable-ish audit story: events and evaluation records in Postgres back forensic review and monitoring (retention and legal holds remain your operational choice in Supabase).

5.3 Value for the business

Faster path to production AI: reduces the classic blocker—“we can’t ship the agent until legal/security signs off on controls.”
Defensible posture when something goes wrong: you can show the payload presented for approval and the policy path taken.
Scalable tenancy: workspace model maps cleanly to customers, business units, or environments (prod vs sandbox) when you configure it that way.

5.4 What makes it defensible as a product (moat-shaped traits)

Policy engine + RBAC + audit together are harder to replicate than a “notification service” because the semantics (matching, ordering, stage machines, OTP) must be correct and secure, not just pretty UI.
Key-bound tenancy and server-side resolution of workspace are security architecture, not a feature flag.

6. Ideal customer profiles & use cases

6.1 Who buys / champions this

VP Engineering / Platform: wants one control plane for many agents and services.
CISO / security architecture: wants separation of duties and explainable gates before agents touch production systems.
Compliance-oriented ops (finance, healthcare-adjacent, regulated internal tools): needs approval evidence and consistent rules.

6.2 Representative use cases

Financial operations agents: payouts, refunds, vendor actions—threshold-based auto vs human approval; multi-stage for large amounts.
Infrastructure / DevOps agents: destructive changes—multi-stage (e.g. developer review → admin) or OTP on production paths.
Customer-support automation: high-impact account changes—single or multi-stage depending on policy.
Internal “copilots” with tool use: any action that should not proceed without payload-visible approver sign-off.

7. Boundaries and honest scope notes

For marketing and evaluation, treat the following as implementation truths:

Email delivery depends on Resend (and correct DNS/sender configuration). Approver experience assumes deliverability.
“Every member with the role receives mail” is powerful and simple; some enterprises will later want assignment, round-robin, or on-call—that would be product evolution, not something to imply exists today without building it.
Pricing and SKU packaging in early PRD documents may not match current go-to-market; align commercial slides with actual packaging and SLAs.

Use this report to describe capabilities that exist; layer pricing, SLAs, and certifications only as they become real.

8. Suggested messaging pillars (for collateral)

One gate, one contract — evaluate + receipt; predictable integration.
Policy before execution — rules are data, evaluated consistently.
Humans in the loop, by design — roles, stages, OTP when risk demands.
Proof, not folklore — evaluations, stages, audit, receipts.
Tenancy you can explain — keys map to workspaces; no client-supplied tenant on evaluate.

9. Document maintenance

When you add major capabilities (e.g. SAML SSO, granular assignment, SOC2 report, new action types), update Sections 2, 3, and 7 so sales and security teams never over-claim. This file is meant to stay closely aligned to shipped behavior.

See also (internal): VIABILITY_AND_GTM_REFERENCE.md — business viability synthesis, pricing hypotheses, GTM tactics, feature roadmap mapping from the March 2026 strategic report, and a unified ordered path to full production.

Generated from the AgentNexusAPI codebase and product architecture as of March 2026.