Change lifecycle ¶

This page explains how a change moves from authoring to governed execution on EAP, and how the two control planes interact along the way.

Lifecycle Overview ¶

flowchart TD
    A[Author change] --> B{Which plane?}
    B -- Agent content --> C1[Project repo PR]
    B -- Runtime config --> C2[enterprise-agent-platform-registry PR]
    C1 --> D1[Project + platform review]
    C2 --> D2[Platform review
MCP scope, access lists]
    D1 --> M[Merge]
    D2 --> M
    M --> S[Ask EAP to deploy approved content]
    S --> X[Governed execution]

A change that touches both planes (for example, adding a new MCP dependency) needs both PRs to land before the new behavior is active.

Stage 1: Local Authoring ¶

You work in your project repo. AGENTS.md, skills, and KB content stay canonical there. Use the Codex onboarding quickstart to set up local iteration against real inputs.

Stage 2: Local Validation ¶

Validate before promoting. A change should prove that it:

• accepts the expected inputs
• calls the right MCP servers
• stops safely when a dependency is missing or unauthorized
• produces evidence plus a useful summary
• respects the approval boundaries declared in the skill

Stage 3: Two-Plane Review ¶

High-risk changes (broadening MCP scope, expanding access lists, changing approval policy) need elevated approval.

Stage 4: Activation ¶

After merge, ask the EAP platform team to deploy the change to the target environment. EAP does not auto-pull from your repo on push or merge — deployment to staging or production is an explicit platform-team action. Once deployed, EAP exposes only the approved content from the registered repo.url + branch, and only the agents, MCP servers, and identities listed in the Registry YAML.

Stage 5: Governed Execution ¶

Once active, every execution runs under EAP's runtime contract:

• platform guardrails injected ahead of the agent prompt
• sandbox isolation per customer / project / agent / session
• LLM access via Cisco LLM Proxy
• network egress restricted to approved MCP servers
• secrets injected by Kubed from Keeper Vault
• approval gates for state-changing actions
• token tracking, audit trail, kill switch

Rollback ¶

If a change misbehaves in production:

1. revert the offending PR (project repo or Registry, or both)
2. or move repo.branch (or envs.<env>.branch) back to a known-good ref
3. if a run is actively misbehaving, the EAP platform team can trigger the kill switch

Never patch around the issue by editing production prompt text outside the review path.

Why This Lifecycle Exists ¶

It solves a production problem, not a documentation problem: it lets agent behavior evolve quickly and keeps every runtime-affecting change reviewable, auditable, and revertable.