The recommendation should become more than a technology-selection matrix. It should define the constitutional architecture of ADAM: what the platform owns, what it governs, what it delegates, and what it refuses to rebuild.

The central architectural thesis is:

ADAM should own the semantics of governed agency, but not the commodity infrastructure used to execute it.

Temporal can preserve workflow state. LiteLLM can normalize model APIs. MCP can expose tools. A2A can exchange tasks. Firecracker can isolate workloads. LLVM can compile code. None of them can determine whether an agent is authorized to perform a particular action, whether the context is trustworthy, whether the resulting artifact is sufficiently assured, or whether an adaptation may be promoted.

That is the ADAM boundary.

The four-category disposition can be realized as four concentric architectural rings.

The dependency direction is important:

• ADAM may depend on adopted infrastructure through ports.
• Adapted components may depend on ADAM contracts.
• External participants may integrate through stable protocols.
• The ADAM semantic kernel must never depend on provider-specific concepts.

For example, claude_session_id, openai_response_id, or temporal_run_id may appear in adapter metadata, but they should never become canonical ADAM identifiers.

Several terms need precise boundaries.

This prevents ADAM Core from becoming tightly coupled to every tool, agent, compiler, and runtime.

The native domain should initially be built around approximately twelve foundational objects.

Principal
Participant
AgentDefinition
AgentRelease
Capability
AuthorityGrant
Invocation
ContextManifest
PolicyDecision
Activity
EvidenceBundle
AssuranceCase
AdaptationProposal

Supporting objects can be added later, but these establish the governance spine.

Temporal workflows, MCP calls, A2A tasks, model calls, shell commands, and CI jobs should all be correlated to a canonical ADAM Invocation.

An Invocation is not merely a request payload. It is a governed unit of work.

“Adopt as-is” should not mean direct use from domain code. It should mean:

Do not fork, reimplement, or extend the internal semantics of the adopted system. Access it through a narrow ADAM-owned port.

Adapted systems should never be connected directly to ADAM Core. Every adapted capability should pass through a governance boundary.

Every coding agent should implement a canonical ParticipantAdapter.

pub trait ParticipantAdapter {
    fn descriptor(&self) -> ParticipantDescriptor;

    async fn negotiate(
        &self,
        request: CapabilityNegotiationRequest,
    ) -> Result<CapabilityNegotiationResponse, AdapterError>;

    async fn start(
        &self,
        invocation: GovernedInvocation,
    ) -> Result<ParticipantSession, AdapterError>;

    async fn stream(
        &self,
        session: &ParticipantSession,
    ) -> Result<ActivityStream, AdapterError>;

    async fn cancel(
        &self,
        session: &ParticipantSession,
    ) -> Result<CancellationReceipt, AdapterError>;
}

The model gateway should sit behind an ADAM Model Execution Gateway.

The wrapper adds:

• Model Passport binding
• Context Manifest hash
• Data classification
• Cost limits
• Token limits
• Retention constraints
• Output schema
• Evidence requirements
• Policy obligations

Do not register raw MCP servers directly with agents.

Introduce a governed MCP lifecycle:

The MCP proxy should:

• Hide unapproved tools
• Bind calls to capability grants
• Validate tool schemas
• Limit input size
• Enforce network policy
• Redact secrets
• Inspect outputs
• Record tool provenance
• Reject version drift
• Support emergency revocation

An MCP tool description is only a claim. ADAM qualification determines whether the tool actually behaves as declared.

LangGraph, CrewAI, AutoGen, and similar systems should be represented as compound participants.

ADAM should not attempt to govern every internal thought or message unless the framework exposes those events reliably.

The wrapper should declare its observability level:

Opaque
Partially observable
Fully instrumented
Deterministically replayable

This affects its maximum assurance level.

For example:

• A fully instrumented LangGraph workflow may expose node transitions, tool calls, state mutations, and checkpoints.
• An opaque remote CrewAI service may expose only task inputs and final artifacts.

ADAM should never pretend these provide equal evidence.

Integrated systems should have independent lifecycles and versioned contracts.

An Agent Card should be ingested as a capability claim, not accepted as proof.

The external A2A agent remains independently operated. ADAM owns:

• Whether it may participate
• What authority it receives
• What data it sees
• Which evidence it must return
• How its output is evaluated

OIDC and SAML identify human or enterprise principals.

SPIFFE-style identities may identify workloads.

ADAM must map them into its own principal model:

Enterprise Identity
        |
        v
ADAM Principal
        |
        v
Role Assignment
        |
        v
Authority Grant
        |
        v
Delegation or Capability Lease

An authenticated identity is not automatically authorized.

External evaluators should implement an Evaluation Contract:

• Evaluation target
• Artifact digest
• Evaluation rubric
• Test data version
• Evaluator identity
• Execution environment
• Results
• Confidence
• Limitations
• Signature
• Reproducibility information

ADAM should support multiple evaluator types:

• Deterministic test runners
• Static analyzers
• Security scanners
• Formal verifiers
• Model-based judges
• Human reviewers
• Domain-specific certification systems

GitHub, GitLab, and CI platforms should remain systems of record for repositories and build execution.

ADAM should integrate through:

• Webhooks
• Commit and tree digests
• Pull-request APIs
• Check-run APIs
• Build attestations
• Deployment events
• Signed status receipts

ADAM owns the lifecycle decision. CI owns the execution of a particular validation pipeline.

The native capabilities can be organized into Rust crates and deployable services.

crates/
  adam-ids
  adam-errors
  adam-domain
  adam-events
  adam-protocol
  adam-invocation
  adam-registry
  adam-context
  adam-assurance
  adam-adaptation
  adam-policy-ir
  adam-agent-ir
  adam-evidence
  adam-adapter-sdk
  adam-execution
  adam-testkit

services/
  adam-api
  adam-coordinator
  adam-registry-service
  adam-context-broker
  pola-pdp
  governor-gateway
  actra-ledger
  assurance-service
  adaptation-controller
  adapter-host
  execution-broker

ADAM should not replace MCP, A2A, ACP, HTTP, gRPC, or CloudEvents.

It should define a governance envelope that can accompany or reference payloads transported through those protocols.

{
  "envelope_version": "1.0",
  "message_id": "msg_01...",
  "correlation_id": "corr_01...",
  "invocation_id": "inv_01...",
  "principal": {
    "principal_id": "principal_01...",
    "type": "agent"
  },
  "participant": {
    "participant_id": "agent_release_01...",
    "passport_id": "agent_passport_01..."
  },
  "authority": {
    "grant_id": "grant_01...",
    "delegation_chain_id": "delegation_01...",
    "expires_at": "2026-08-01T05:00:00Z"
  },
  "policy": {
    "decision_id": "decision_01...",
    "bundle_digest": "sha256:..."
  },
  "context": {
    "manifest_id": "context_01...",
    "manifest_digest": "sha256:..."
  },
  "execution": {
    "risk_tier": "T3",
    "environment_profile_id": "env_profile_01..."
  },
  "evidence": {
    "profile_id": "evidence_profile_01...",
    "activity_stream_id": "stream_01..."
  },
  "payload": {
    "protocol": "mcp",
    "content_type": "application/json",
    "reference": "payload_01..."
  },
  "signatures": []
}

The payload may be:

• An MCP tool call
• An A2A task
• An ACP session event
• A model request
• A Temporal workflow signal
• A GitHub check result
• A custom enterprise API request

The envelope carries governance semantics without attempting to redefine the payload protocol.

This is one of the most important architectural decisions.

Actra should have two storage views.

The Context Broker should not return an unrecorded string of prompt text.

It should construct a manifest containing:

• Source identity
• Source digest
• Source version
• Selection reason
• Retrieval query
• Retrieval score
• Trust classification
• Epistemic status
• Data classification
• Transformation history
• Token representation
• Ordering
• Exclusions
• Context budget decision

The rendered prompt is transient. The Context Manifest is the governed record.

Ana should prevent a common agent-memory failure: repeated claims gradually becoming accepted facts.

Recommended state transitions:

Every transition should identify:

• Who or what proposed it
• What evidence supports it
• What evidence contradicts it
• Which authority approved it
• When it expires or must be reviewed

An agent should never directly mutate its own production configuration.

Adaptation classes should be governed differently.

Policy and authority adaptations should never be autonomously approved.

Do not begin by creating custom MLIR dialects for the entire system.

For enterprise deployment, centralizing all execution through one ADAM cluster will create latency, data residency, and blast-radius problems.

Use:

• A logically global control plane
• Regionally or organizationally local execution cells

Execution cells should continue enforcing the last valid policy set during a temporary control-plane outage, but should fail closed for new high-risk authority grants.

The strongest first implementation is not the full Agentic VM. It is a governed coding-agent lifecycle.

The following rules should be treated as non-negotiable.

1. Provider objects never enter the canonical domain.

2. Every side effect passes through a Governor enforcement point.

3. Pola cannot execute actions, and Governor cannot invent policy.

4. Every invocation binds identity, authority, purpose, context, policy, and evidence requirements.

5. Context is represented by an immutable manifest, not only a rendered prompt.

6. Agent output is a proposal until independently validated.

7. Evidence is a mandatory product of execution, not an optional logging feature.

8. External framework agents are treated as participants, not embedded as the ADAM kernel.

9. Adopted components are replaceable through ports.

10. Adaptations are versioned proposals with experiments and rollback.

11. No agent approves its own elevation of authority.

12. A protocol declaration is a capability claim, not evidence of conformance.

13. Temporal provides durability, not domain truth.

14. OpenTelemetry provides operational signals, not assurance semantics.

15. LLVM provides compilation infrastructure, not an agent security boundary.

The final architecture can be summarized in one sentence:

ADAM converts external models, agents, tools, frameworks, protocols, and runtimes into governed participants by binding every consequential operation to canonical identity, authority, context, policy, execution, evidence, assurance, and lifecycle semantics.

The decisive move is not to build replacements for LiteLLM, Temporal, MCP, A2A, Firecracker, or LLVM.

It is to build the governance kernel that makes them composable, attributable, controllable, and continuously assured as one agent lifecycle system.