EAP platform architecture ¶

EAP separates what an agent does (a selected customer-owned agent repository) from how it is allowed to run in production (Registry YAML), and runs the approved combination through a governed Codex execution plane.

This page describes EAP's stable operating model and responsibility boundaries. For internal components, request flow, sessions, and protocols, see EAP architecture.

End-to-End Operating Model ¶

This view follows one EAP project from customer-owned content and reviewed configuration through the EAP runtime to its callers, model provider, tools, and target systems.

A customer team may own multiple agent repositories. Each EAP project selects one repository and branch through its Registry YAML.

flowchart TB
    subgraph Team[Customer team]
        Repo[Selected customer-owned agent repo
AGENTS.md, Agent Skills, documents,
scripts, CLIs, optional repo-local MCP tools,
and human-approval rules]
        Local[Local Codex
development, testing,
evaluation, and validation]
        RegistryYAML[Agent Registry YAML
selected repo and branch,
runtime and production MCP configuration,
LLM identity, and callers]
        ObtainCredentials[Customer-provided credentials
LLM Proxy and downstream APIs/MCPs]
        Repo --> Local
    end

    Registry[EAP Agent Registry repo
owned by the EAP team]
    Keeper[Keeper
EAP-owned path]
    Review[EAP onboarding and change review]

    subgraph EAP[EAP governed runtime]
        Gateway[EAP UI and API gateway]
        Codex[Codex project runtime
app-server]
        Controls[Governance, guardrails,
reliability, and operations]
        Gateway --> Codex
        Codex --- Controls
    end

    People[People] -->|Use the EAP UI| Gateway
    Applications[Applications] -->|Invoke the EAP API| Gateway
    RegistryYAML -->|Add or update| Registry
    ObtainCredentials -->|Provide for storage| Keeper
    Repo -->|New Agent or release| Review
    Registry -->|New or updated configuration| Review
    Review -->|Approved inputs| Codex
    Keeper -->|Runtime credentials| Codex
    Codex --> LLM[Cisco Collab LLM Proxy
model provider]
    Codex --> MCP[Approved MCP servers]
    MCP --> Systems[Target systems]

The customer team owns the Agent's business behavior and validates it locally. EAP owns the Registry, review boundary, credential handling, governed runtime, and common platform controls.

Production behavior is the intersection of the reviewed agent repository and the approved Registry configuration. A repository change can change agent behavior, but it cannot on its own grant new production callers, credentials, or MCP access.

Agent Repositories And Reviewed Configuration ¶

Customer-Owned Agent Repositories ¶

A team may own one or more agent repositories. Each repository should group agent content that shares a clear purpose, ownership boundary, and lifecycle.

An agent repository may contain:

AGENTS.md and supporting documents
Agent Skills
scripts and CLIs
optional repo-local MCP tools
human-in-the-loop rules
project-specific assets and tests

A repo-local MCP tool is appropriate when its implementation is owned, versioned, tested, and released with that repository.

Remote or shared MCP servers are deployed and operated separately. Agent Skills may document dependencies on those servers, but the server implementations do not belong in the agent repository.

Any MCP made available in production—whether its implementation is repo-local or externally operated—must be explicitly approved through the project's Registry configuration.

Two Reviewed Inputs ¶

Each EAP project is governed through two independently reviewed inputs:

Reviewed input	Defines	Ownership and review
Selected customer-owned agent repository	business behavior, working knowledge, Agent Skills, scripts, CLIs, optional repo-local MCP tools, human-approval rules, and project assets	owned by the customer team; reviewed by project or domain owners and by EAP during onboarding and release review
Agent Registry YAML	runtime selection, selected repository and branch, production MCP configuration, LLM identity, authorized callers, and credential environment-variable references	proposed by the customer team; stored and reviewed in the EAP-owned Registry repository

The two inputs can evolve at different rates, but both must be approved before their combined behavior becomes active in EAP.

Responsibility Boundaries ¶

Participant	Responsibility
Customer team	owns one or more agent repositories, defines business behavior, develops repo-local tools, validates the Agent locally, documents MCP dependencies, and provides required credentials
EAP platform team	owns the Registry repository, onboarding and change review, credential storage and injection, gateway, governed runtime, common controls, and platform operations
Authorized people and applications	invoke the Agent through the EAP UI or API and provide required inputs or approval decisions
Cisco Collab LLM Proxy	provides the managed production model path
Remote or shared MCP owners	deploy and operate their MCP servers and own server availability, RBAC, tool behavior, and target-system integration

This separation lets customer teams evolve business-specific agent capabilities without operating a server-side agent platform, while EAP governs how approved content is exposed and executed in production.