Common Questions
Governing an agent workforce. Clear answers, no fluff.
EAA treats the autonomous agent workforce as the fifth domain of enterprise architecture.
Alongside the classic four domains — business, data, application, and technology — EAA adds the agent workforce and describes it in four layers: Agent/Workforce, Capability/Tool, Control Plane, and Governance.
The point is to reason about agents the way an organization already reasons about people, systems, and data — with structure, not ad-hoc scripts.
Because an autonomous agent is a workforce, not just another application.
Agents take actions, hold capabilities, and compose behavior across sessions. The existing four EA domains have no home for a non-human actor that decides at runtime, so EAA gives it one — and structures it into Agent/Workforce, Capability/Tool, Control Plane, and Governance layers.
WHO and HOW are solved problems. WHY is the open one.
WHO is identity and authentication — is this the agent it claims to be. HOW is permissions and tools — is it allowed to call this capability. Neither answers WHY: is an already-authorized action actually sound at the moment of execution, and does the trajectory of authorized actions stay sound over time?
WHO says the agent is real. HOW says the action is permitted. WHY asks whether a permitted action is a good idea right now — and that is the layer EAA concentrates on.
EAA is for the people accountable for an agent workforce, not just for standing it up.
Specifically:
- CIOs and enterprise architects placing agents inside a target-state architecture
- CISOs and security architects who need runtime evidence, not just authentication
- Platform teams operating agents across more than one vendor cloud
- Anyone who values verifiable behavior over marketing assurances
Not for: teams looking for a turnkey managed product with guaranteed outcomes. EAA is a reference model and an open-core engine — you architect with it.
It's the open-core WHY-layer policy engine.
constitutional-agent is published on PyPI (v0.8.0, roughly 330 downloads per month). It evaluates whether an already-authorized action is sound and whether a trajectory of actions stays sound across sessions.
It's the WHY layer of EAA expressed as installable code — the piece you can pick up and run against your own agents today.
HRAO-E is a live autonomous organization that governs its own operations under the EAA model.
It exists to prove the framework in practice rather than on paper. It is:
- A reference implementation — a worked example, not a product to buy
- A running system that generates real governance telemetry
- The source of the refusal data cited in the published research
- Characterization of the model in operation, not a certification of your deployment
It shows what the four layers look like when something actually runs on them.
Three independent lines of evidence — all characterization, not certification.
Adversarial testing:
- An agent-security test harness with 604 tests across 43 modules
- Probes the engine the way an attacker would
- Open on GitHub (roughly 22 stars)
- Separates exploit findings from compliance-mapping gaps
Live telemetry from the reference implementation:
- HRAO-E runs continuously under the governance model
- 30,496 governance refusals across 451,163 evaluated events
- Collected over roughly six months of operation
- Published as a preprint, not asserted from memory
We say "characterization" and "reference implementation" — never "certified," "audit-ready," or "production-hardened."
Yes — three preprints with DOIs, authored by Michael K. Saleme.
- The EAA position paper — DOI 10.5281/zenodo.21105314
- Authorized but Composed, on cross-session risk composition — DOI 10.5281/zenodo.21400261
- Authorized but Refused, the 30,496-refusal telemetry — DOI 10.5281/zenodo.21263262
- Plus three public-comment submissions concerning NIST AI 800-2 (CAISI acknowledged receipt)
See the Evidence page and Research for the full trail.
That authorized actions still get refused — and that refusals compose across a trajectory.
Across 451,163 evaluated events, the reference implementation refused 30,496 of them on WHY-layer grounds — actions that identity and permission checks would have let through. Composition matters because risk that looks fine one step at a time can accumulate over a session.
The findings are reported in the Authorized but Refused and Authorized but Composed preprints, from a single running reference implementation.
It produces the kind of evidence those obligations ask for.
The WHY layer keeps a durable, per-decision record of why an authorized action was allowed or refused. That supports, but does not replace, a compliance program:
- A per-decision rationale trail useful for a Fundamental Rights Impact Assessment
- Runtime records aligned with EU AI Act transparency and record-keeping expectations
- A mapping to 19 of 20 testable AIUC-1 requirements — a mapping, not a certification
These are aids to your assessors, not a substitute for them.
The work is not NIST-validated, and we don't claim it is.
What is true: three public-comment submissions concerning NIST AI 800-2, which CAISI acknowledged receipt of. That is an engagement, nothing more — we're careful to describe it precisely rather than imply endorsement.
We'd rather state the exact status than borrow authority we haven't earned.
The incumbents own WHO and HOW. EAA fills WHY, and stays vendor-neutral.
The major control planes are excellent at identity, orchestration, and tool permissioning — inside their own clouds. EAA's WHY layer is different in kind:
- It sits at execution time, judging whether a permitted action is sound
- It is vendor-neutral — it works wherever the agents run
- It complements a control plane rather than replacing it
Not a control-plane competitor. Keep your control plane; EAA adds the runtime WHY judgment it doesn't make.
The engine is open-core, and the framework and research are public.
constitutional-agent is on PyPI and free to install (v0.8.0). The position paper and preprints are openly available under their DOIs. You can evaluate the whole WHY layer without a sales conversation.
Read it, install it, and inspect the evidence — in that order.
A practical path:
- Read the framework position paper to place agents in your target-state architecture
- Install the open-core constitutional-agent package and run it against a real agent
- Review the reference implementation and the published refusal telemetry
- Compare notes on your own workforce via the low-pressure design-partner line
The design-partner line is research@cognitivethoughtengine.com — no funnel, no pressure.
Because governing an agent workforce is an enterprise-architecture problem that didn't have a domain.
The work is authored by Michael K. Saleme, an enterprise agent architect with a three-decade background in enterprise architecture, integration, and security. The approach:
- Name the missing domain and give it a reference model
- Ship the WHY layer as open-core code, not a slide deck
- Prove it in a live reference implementation and publish the telemetry
- State the evidence precisely — characterization, never certification
That's what "reference implementation" is meant to mean here.
See where the agent workforce fits in your target-state architecture — the framework, the open-core engine, and the evidence trail.
Read the Framework