Policy as Commander’s Intent
Three policy layers published as MCP aspects — each task pulls in what the moment requires
Policy Layers (published through MCP)
1. Strategic Policy
What is forbidden • what success looks like
• Regulatory boundaries (GDPR, HIPAA, FSMA) • Ethical floors (no discrimination, no dark patterns) • Mission outcome (e.g. “livability before repair sequence”)
2. Doctrinal Preferences
How this organization handles trade-offs
• Speed vs. accuracy weights • Cost vs. customer-experience priorities • Risk appetite by segment / quarter
3. Situational Context
What is true right now in this instance
• Goal of THIS instance (commander’s intent for this case) • Peer-task / peer-instance state • Live cluster variables, sensor signals, market conditions
MCP Gateway
policy is just another aspect
Agentic Tasks (swarming)
Claims Triage Task
consults: unfair-claims floor, speed weight, peer claims
Replenishment Task
consults: FSMA shelf-life floor, shrink weight, instance goal
Disclosure Task
consults: required disclosure list, customer language
Triage Re-Evaluation
consults: SALT doctrine, livability priority, peer state
Reallocation Task
consults: budget guard-rails, attribution lineage
Audit & Lineage Substrate — the return path
Every MCP call is logged. Every task records: which policy aspect was in effect, which doctrine weighted the decision, and what situational context was true. Compliance verifier scans the trail. Drift detector compares behavior to intent. Operators trace any decision back to the policy that produced it.
Commander’s Intent > Step-by-Step Doctrine
Train the agents to know the rules. Publish the intent. Trust the swarm to act — and let the audit trail prove it.
No point-to-point wiring of regulation into the BPMN. No master controller carrying every domain rule. Policy travels with the aspect, not with the diagram.
References: arXiv:2603.27299 (Declarative Policy Compilation), arXiv:2603.18096 (Trace-Based Assurance), Arsanjani & Bustos (Packt 2026)