Enterprise Agent Platform (EAP) ¶

From individual Codex use to a governed server-side digital teammate.

EAP lets CCPS teams run proven Codex workflows as governed services that authorized people and applications can invoke.

The Codex Adoption Journey ¶

Teams get the most value from EAP when they first learn how Codex works, then turn their own ways of working into shared assets, and finally move the workflows that need service access or centralized governance to EAP.

Stage 1 — Learn Codex ¶

Codex can write and review code, explain technical topics, investigate logs and errors, and assist with knowledge work. It is broadly knowledgeable and capable, but it is not infallible. Teams should use it on real work, review its output, and learn what to delegate, what to verify, and what context to provide.

Stage 2 — Bring Codex Into The Team ¶

The next step is to turn the team's way of working into shared assets that both people and Codex can understand and use.

A team may own one or more agent repositories. Each repository groups agent content that shares a clear purpose, ownership boundary, and lifecycle, and should be managed with the same care as code.

Repo-local MCP tools are appropriate when their implementation is owned, versioned, and tested with that agent repository. Remote or shared MCP servers are deployed and operated separately. Documenting an MCP dependency in an agent repository does not include or authorize that server; EAP production access is controlled by the project's approved Registry YAML.

Experienced team members develop, test, evaluate, and validate each agent repository locally. Once its skills consistently produce acceptable results, the team can distribute and use them in daily work with local Codex.

Stage 3 — Run And Govern Codex On The Server ¶

Local success creates two reasons to move a workflow to a governed server-side environment.

People And Applications Need A Service They Can Call ¶

With local execution, an engineer remains a station in the invocation path:

Alert or request → Engineer → Local Codex

With server-side execution, authorized people and applications can invoke the Agent directly:

People or applications → EAP → Server-side Codex

This removes the engineer from the invocation path while preserving human decisions for gated actions.

Local Execution Creates Governance And Security Risks ¶

An Agent running on an engineer's laptop may be able to reach local files, sensitive data, remote systems, databases, and network destinations available to that engineer. The engineer's credentials and privileges may also let it open or change protected resources.

An Agent mistake, misunderstood instruction, or prompt injection can turn that reach into production damage or sensitive-data exposure. Actions may appear under the engineer's identity, evidence remains scattered across local systems, and there is no central place to attribute, audit, or stop runs across the team.

Local Codex is the right place to build and prove an agent repo. Workflows that must become a service, or that change production systems and require a distinct identity, contained execution, and centralized governance, belong on a governed server-side runtime.

What EAP Is ¶

Running Codex on a server is not enough. A dependable shared service also needs governance, guardrails, reliability, and continuous platform operations.

EAP runs a customer team's approved agent repo in a governed server-side Codex environment. It uses Cisco Collab LLM Proxy as the model provider and approved MCP servers as tools.

flowchart TB
    People[People] --> UI[EAP UI]
    Applications[Applications] --> API[EAP API]

    subgraph Customer[Customer team owns the business-value layer]
        Repo[Working knowledge
Agent Skills
Tools]
    end

    subgraph Platform[EAP owns the common platform layer]
        UI --> Codex[Governed server-side
Codex Agent]
        API --> Codex
        Controls[Governance
Guardrails
Reliability and operations] --- Codex
    end

    Repo --> Codex
    Codex --> LLM[Cisco Collab LLM Proxy]
    Codex --> MCP[Approved MCP servers]
    MCP --> Systems[Target systems]

See the End-to-End Operating Model for the complete path from local validation and reviewed inputs through the EAP runtime.

Customer teams focus on the working knowledge, Agent Skills, and tools that create business value. EAP owns the common platform work:

See EAP Status for the availability and maturity of each capability, Runtime and governance for the control model, and Operations for operational details.

Architecture Direction ¶

CCPS teams should use EAP for internal server-side Codex agents instead of building separate hosted-agent runtimes. Production-changing Agent workflows should run within a governed server-side environment, not from an engineer's local Codex session.

This direction lets customer teams spend scarce engineering capacity on business-specific Agent capabilities instead of common platform plumbing. Use cases with special requirements can go through PE architecture review.

Current Availability ¶

• Commercial Production — Available. EAP is operating and open for onboarding.
• W4G — Planned. Deployment is planned by the end of F27 Q1.

See EAP Status for capability-level status, current limitations, and delivery targets.

Choose The Right Execution Model ¶

Some work is best handled by one Agent that uses working knowledge, instructions, and tools to complete the whole job. Other work needs a deterministic pipeline in which a workflow engine fixes the route, maintains state, and advances work through bounded stations.

In a pipeline, each station should use the simplest worker that can reliably do the job: code for exact behavior, a direct LLM call for one bounded inference, an EAP Agent for adaptive investigation and tool use, or a human for accountable decisions and exceptional cases.

The workflow engine owns pipeline state and station transitions. EAP runs the governed Codex Agent when a station needs one. See Use EAP in a Workflow Pipeline for the complete design model and an incident-response example.

Onboard An Agent ¶

When the agent repo is ready, onboarding follows four steps:

1. Register. Add a YAML file to the EAP Agent Registry repo that identifies the customer-owned agent repo and branch, required MCP servers, authorized callers, and credential environment-variable names.
2. Review. EAP reviews the agent repo and Registry configuration for prompt-injection risks, risky commands, data-exfiltration paths, hard-coded secrets, new or untrusted MCP servers, and other security or governance concerns. Human reviewers make the final activation decision.
3. Credentials. The customer team obtains and provides its Cisco Collab LLM Proxy credentials and required downstream API or MCP credentials. EAP ensures that they are stored in an EAP-owned Keeper path.
4. Activate. EAP checks out the approved branch and starts the governed Codex project runtime.

After activation, people use the EAP UI and applications use the EAP API. New agent releases and Registry changes go through review before deployment.

The recommended path for a team onboarding its first Agent is to validate the agent repo locally, follow the Codex onboarding quickstart, and submit the agent repo and Registry configuration for review.

When EAP Is Not The Right Fit ¶

EAP is not a general-purpose code-hosting platform or a deterministic workflow engine. Put exact, repeatable behavior in code or a tool. Use a workflow engine when the solution must own a fixed pipeline, its state, and station transitions. If EAP's operating model does not meet a use case's requirements, take it through PE architecture review.

Where To Go Next ¶