Dora NodaAn AI agent does not need a perfect model to make a damaging production change. It only needs one believable but stale answer: the old on-call team, the image tag that never reached production, or a dependency map that missed the database it is about to restart.
That is why the rush to give agents deployment and incident tools should begin with an unglamorous question: can the platform prove that the context it is about to hand an agent is current, attributable, and safe to act on? A portal that is merely easy to browse is not enough once the same catalog becomes an agent's control surface.
What Port, Cortex, and Backstage do—and do not—prove
There is a real market signal behind this question. In December 2025, Port announced a $100 million Series C and described its next layer as an “agentic SDLC” built on its existing catalog, self-service actions, and scorecards. Its stated use cases include agents handling tickets, incidents, vulnerabilities, and standards with people retaining control. Port's funding announcement is evidence that commercial IDP vendors see catalog-mediated agent work as a major direction; it is not evidence that any particular catalog is ready to grant production authority.
Cortex's 2026 benchmark gives the caution a sharper edge. Its report says that, in the data it analyzed, incidents per pull request rose 23.5% and change failure rate rose 30% as AI increased code volume. Those figures describe an observed benchmark relationship, not a universal causal estimate and not a verdict on every AI workflow. Still, they are a useful reminder that faster code production makes wrong context and weak delivery controls more expensive. Cortex's 2026 Benchmark Report
Backstage supplies the open-source implementation reference, not a magic answer. Its Software Catalog is designed to record ownership and metadata alongside code, then ingest and process those records into a graph. It also now models AI skills, governance rules, and MCP servers as catalog resources. Backstage's catalog overview and its AI catalog model show the shape of a self-hosted foundation. The operational contract below is the extra work a team must do before treating that foundation as agent context.
The catalog hygiene contract: make bad context fail closed
The core deliverable is not another dashboard. It is a contract between the catalog, its sources, and every agent that reads it. The freshness windows below are example starting points, not universal thresholds: a five-minute deployment-status target may be excessive for a batch service and dangerously slow for a high-risk rollback. What matters is that each field has an authority, an observable age, and a defined safe response when it cannot be trusted.
| Required context | Authoritative source | Example freshness / validation | Agent behavior when absent or stale |
|---|---|---|---|
| Service identity and lifecycle | Versioned catalog-info.yaml or equivalent in the repository | Schema validation on merge; reconcile each default branch change | Do not guess a similarly named service; return discovery-only results |
| Human owner and escalation route | Git CODEOWNERS plus an identity/on-call system | Owner resolves to an active group and current rotation | No production action; create or route a task to the platform team |
| Repository and immutable revision | SCM API and protected build record | Commit SHA must match a signed or approved build | Never deploy a branch name or “latest” tag as a substitute |
| Deployable artifact | Registry and CI provenance/attestation | Digest exists, is allowed by policy, and was built from that revision | Stop; ask for a new build or human confirmation |
| Environment, current rollout/rollback state, region, and endpoint | Cluster inventory and deployment controller status | Reconcile on controller event; show last observation time and last known-good artifact | Do not infer production from a URL or namespace name, or assume a rollback target still exists |
| Dependencies and operational links | Declared relations enriched by runtime/monitoring data | Broken references, orphaned records, and missing runbooks are visible | Limit the agent to a plan; require an owner to resolve the gap |
| Policy scope and approvals | Versioned policy-as-code and change system | Evaluate against the exact action, environment, and actor identity | Deny by default; do not treat an old approval as a blanket permit |
This table changes the meaning of “the agent can look something up.” An answer should carry provenance—where it came from, when it was observed, and whether it passed validation—not just a convenient summary. A field that is not fresh enough for a deployment can still be useful for a human's investigation. It is simply not an authorization token.
Backstage's own catalog lifecycle makes this distinction practical. Its processors can ingest and validate data, and entities that lose their upstream relationship can be marked orphaned. A self-hosted portal should surface those conditions to agents as first-class uncertainty, rather than quietly leaving an attractive but disconnected record available for action. Backstage's entity lifecycle documentation
A deploy request should stop safely when the record lies
Consider an agent receiving: “Deploy payments-api to production, then roll back if error rate rises.” A weak catalog returns an owner, repository, and a green build badge. A usable agent contract returns the evidence the agent needs to reason about the request:
{
"service": "payments-api",
"owner": { "group": "payments", "onCall": "payments-primary", "observedAt": "2026-08-29T16:58:00Z" },
"revision": "7b41d0e",
"artifact": { "digest": "sha256:…", "provenance": "ci-run-1842", "policy": "passed" },
"target": { "environment": "production", "region": "hel1", "observedAt": "2026-08-29T17:01:00Z" },
"rollback": { "artifactDigest": "sha256:…", "runbook": "docs/runbooks/payments-rollback" },
"approval": { "required": true, "scope": "one production rollout", "status": "pending" }
}The agent can now make a bounded plan: verify that the revision maps to the immutable artifact, evaluate the production policy, request the named approval, initiate the rollout, and watch the declared error-rate signal. If that signal breaches the agreed threshold, it can propose or execute the already-authorized rollback only if the rollback digest and runbook are still valid.
Now change two fields. The owner was deleted during a team reorganization, and the registry no longer has the recorded digest. The safe answer is not “deploy the newest image and notify the old Slack channel.” It is: I cannot establish a current owner or an approved artifact. Here is the conflicting evidence, and here is the human queue that must resolve it. That refusal is not an agent failure. It is the catalog doing its most important job.
The same rule protects incident response. An agent may summarize stale topology during a read-only investigation, but it should not restart a supposedly isolated dependency or widen a network policy when the dependency graph is incomplete. Read authority and write authority are different products.
Build a reconciled system, not a spreadsheet with an MCP endpoint
For a self-hosted IDP, the durable pattern is to let each system own the facts it is best placed to observe, then reconcile them into a queryable graph:
- Git-held descriptors define service identity, intended ownership, lifecycle, documentation, and declared dependencies. Reviewable changes make intent auditable.
- SCM and
CODEOWNERSresolve the repository, revision, and accountable group. They should not be copied manually into a portal form. - CI, an image registry, and deployment controllers provide artifact digests, attestations, rollout state, and the cluster's actual target.
- Kubernetes, Cluster API, and observability systems supply live environment, machine, health, and alert context. They are observations, not replacements for ownership or policy.
- Policy-as-code and the change system decide what an agent may do. The agent asks for a decision; it does not recreate policy in a prompt.
This is why “self-hosted” should not mean “every fact lives in the portal database.” Use read-only ingestion where a remote system is authoritative, keep write paths in the system that can audit them, and attach provenance to each field. Backstage supports a read-only catalog mode for mirror-style ingestion; that is a useful default for facts discovered from external sources. Backstage's catalog configuration
Run quality checks continuously. Examples include components without a resolvable owner, production services with no artifact provenance, controller status older than its SLO, dependencies pointing to deleted services, and runbooks missing for an action an agent is allowed to request. Scorecards are useful only when their failures lead somewhere: block elevation to a higher authority stage, open a named remediation task, or visibly constrain the agent's answer.
MCP does not change this architecture. It is a transport for tools and context, not a freshness system or an authorization model. Expose narrow tools such as get_service_context, plan_deployment, and request_approval; avoid a broad “run arbitrary cluster command” tool. Each result should state its policy decision and the age of the source observations.
Earn operational authority in stages
No freshness target turns a new agent into an experienced operator overnight. A staged rollout gives the team evidence that the catalog contract works under normal drift and exceptional change.
| Stage | What the agent may do | Control | Evidence to advance |
|---|---|---|---|
| 1. Discover | Read catalog and explain uncertainty | No writes; show provenance and gaps | High coverage of owners, artifacts, and targets; known gaps have owners |
| 2. Advise | Produce deploy/incident plans | Human compares plan with runbook | Plans cite current fields and have a measured low correction rate |
| 3. Request | Open a scoped, human-approved action | Approval binds action, target, artifact, and expiry | Audit trail shows approvals cannot be reused outside scope |
| 4. Act narrowly | Execute a low-risk, reversible runbook | Allowlisted action, preconditions, rollback, alerts | Drills prove the stop conditions and rollback path work |
| 5. Expand | Automate additional bounded actions | Per-service policy, budget, and continuous review | Error and override data supports broadening one action class at a time |
The stages are deliberately about authority, not model cleverness. An excellent agent with an incomplete catalog should stay at stage one. A modest agent with strong provenance and a narrow, reversible runbook can be useful at stage four. The limiting factor is the safety envelope around the action.
The self-hosted deployment-platform implication
A git-push PaaS already observes a valuable subset of this graph: an app/service identity, repository revision, build/deploy state, environment endpoint, and controller-owned status. For a Bex-like self-hosted platform, those facts can ground an agent much better than a chat transcript or a hand-maintained wiki. They are still not enough by themselves.
Before granting an agent production writes, enrich that deployment record with a current owner and escalation route, policy scope, approval binding, provenance, and a verified rollback path. Then make uncertainty visible and make refusal normal. That turns “AI-native operations” from an invitation to let a model improvise on a cluster into a system where every useful action has evidence, limits, and a human path when the evidence is missing.
Bex.co is the open-source, AI-native Render alternative—push a git repo and get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
