Agentic Architecture for a Multi-Domain Operations Platform

Cursor is the control plane: persistent agent identities, always-applied rules, CI that refuses unattributed work, and a daily architecture review. Agents move fast inside a perimeter, not around it.

1. Problem

A multi-domain system cannot be owned by one “full-stack” agent or one hero engineer. If every chat can touch every surface:

• Schema, identity, and vendor tokens drift.
• Production becomes an experiment sandbox.
• There is no audit trail of who changed what.
• Generative tooling writes code; it does not become an organization that can be governed.

The design goal: integrate autonomous agents into execution layers, with guardrails, and with a review function that manages debt and standards. Architecture first, then staffing and tooling.

2. Operating model — three planes

                    ┌─────────────────────────────────────┐
                    │     CONTROL PLANE (Cursor)           │
                    │  persistent chats · rules · cloud    │
                    └─────────────────────────────────────┘
                                      │
           ┌──────────────────────────┼──────────────────────────┐
           ▼                          ▼                          ▼
   ORCHESTRATION                 REVIEW                    EXECUTION
   Manager agent              Architect agent               Domain agents
   (route, sequence,          (standards, debt,            (commerce, identity,
    hand off — no             scorecards, workers —           inventory, comms,
    domain code)              no section ownership)         reporting, integrations
                                                            shell)
                                      │
                                      ▼
                           POLICY-AS-CODE + CI
                     data contracts · prod safety ·
                     commit attribution · schema check

Manager (orchestration)

Plans cross-domain work. Does not implement. Emits ordered handoffs: owner, in/out of scope, commit identity, done-when.

Architect (standing review)

A review function with authority encoded in rules:

• Health checks produce scorecards (severity, owner, fix, risk of inaction) — not silent rewrites.
• Design review before feature work: fit to existing bounded contexts, block anti-patterns.
• Remediation is delegated: workers for bounded fixes, domain handoffs when a surface must keep an owner.
• Updates standards (ADRs, agent rules) when the system shape changes.

Domain agents (execution)

One durable identity per bounded context — customers, commerce, inventory, hospitality, communications, reporting, financial connectors, DevOps, and an integrations shell that catalogs vendors without taking OAuth from the domain that owns the product.

They are accountable owners with a data contract (schema → migrate → store loaders), APIs they may call, JSON files they may not read from routes, and a commit prefix so deploy history shows which agent shipped.

Cursor chats are not renamed. Identity is the org chart. That is how an agentic org stays from collapsing into one undifferentiated assistant.

3. Cursor as the control plane

Cursor is not used as an IDE with autocomplete. It is the operating system for a multi-agent architecture practice.

Hands-on stays on architecture decisions, contracts, and review scorecards. Domain execution is delegated once the framework is set — including to other Cursor agents, not only to people. The rules hold whether a human is in the chat or a cloud agent is.

4. Policy-as-code

Standards the Architect is not allowed to weaken:

1. Canonical schema — YAML is the model. Types and demo data follow. No JSON-as-schema.
2. Postgres first, fail soft — loaders try the database; demo JSON only if it is unreachable. Production is not stranded on a laptop file.
3. Shared identity spine — customer_id / employee_id. Domains reference parties; they do not clone PII.
4. Soft delete — entity rows are never hard-deleted. Agents that “clean up” with DELETE FROM are out of policy.
5. Production safety — constrained production hosts: no compile/npm ci on the live box. Ship via CI or a linux/amd64 build + rsync. Encoded as an always-applied rule so a well-meaning agent cannot take the site down. The rule exists because that failure mode already happened.
6. Scope perimeter — agents may not touch infrastructure outside the owned properties and accounts.
7. Secrets — env and token files; never in git; OAuth scopes minimal.
8. Public vs internal APIs — public routes namespaced; auth on protected surfaces.

How a change gets through review

1. Operator states success criteria.
2. Architect maps surface → owner (or Manager emits handoffs).
3. Schema change: YAML → generate → migrate → seed → live schema check.
4. Domain agent implements via store loaders, not file I/O in routes.
5. Commit must carry the owning agent’s prefix or CI blocks deploy.
6. Architect verifies done-when; residual risk stays on a scorecard (and can become a tracked issue, without duplicating ones that already exist).

Generative agents produce diffs. The perimeter and the audit trail are not optional.

5. Agents in execution layers

Agents do not sit in a sidecar chatbot. They own the systems that take money, send email, sync inventory, and connect vendors.

Vendor classes (not a list of “which SaaS we own”):

New vendor: catalog row → owning domain’s status API + card → optional inbound webhook in the traffic registry. The shell does not grow into a dump of every SaaS.

6. Guardrails

Contracts before more agents. Velocity with a perimeter.

7. Ecosystem health

Operational telemetry the review function actually uses:

• Webhook health: volume, readiness, event log (payments, email, commerce, Slack).
• Schema check: live database vs canonical model.
• Deploy pipeline: attributed commits; queued production deploys; no on-box builds.
• Architecture scorecards: severity × owner × inaction risk.
• Issue hygiene: daily review comments on open debt instead of spawning twins.

The canonical model is not the SaaS vendor’s UI. Schema lives in YAML; runtime is Postgres-first.

8. A change, end to end

Example: add a vendor.

1. Catalog — row with category, owning domain, auth class, status API. Shell owns information architecture; domain owns tokens.
2. Architect — if it touches shared identity or a second source of truth, scorecard before build.
3. Domain agent (in Cursor) — OAuth routes, Connect card, no secrets in git.
4. If inbound HTTP — signed webhook in the traffic registry; health dashboard picks it up. No parallel slug product unless routing exists.
5. Commit — owning agent prefix. CI rejects unlabeled work.
6. Deploy — CI linux build; never compile on the constrained production host.
7. Health — status card + webhook volume; daily review if the pattern drifts.

Catalog, owner, contract, gate, telemetry.

Related: Governed AI Workflows for Marketing and Embrace AI.