IDPs aren't dead, they're getting an agent interface

Lucas Duarte is a principal specialist for agentic transformation at AWS, and Tiago Reichert is an AWS container specialist who works with startups in Latin America. In this 27-minute BackstageCon North America session, they walk through what a Backstage-based internal developer platform (IDP) needs once developers, and the agents working for them, stop using the portal UI. Together with Jaime Nagase they wrote the Packt book Agentic AI for Platform Engineering, and the demos come from its companion repo.

The title is a provocation. The claim is that IDPs are evolving, not dying: the catalog, templates and GitOps you already have become the guard rails that keep a non-deterministic agent inside known boundaries.

Why the portal is losing its users

They open with a Cloudflare study showing that more than half of internet traffic now comes from agents and AI, not people clicking through front ends. Developers are the same: they work in Claude Code, Kiro or Codex and don’t want to leave their coding assistant to use an internal system.

A typical platform today is built in layers:

1. Resources: databases, buckets, applications.
2. Blueprints: best-practice abstractions, such as an S3 bucket plus a least-privilege IAM role plus a service account that ties an application to the bucket.
3. Bundles: several blueprints combined for a business outcome, like a three-tier or BI application.
4. Catalog: where developers find a blueprint, deploy it and customise it. Backstage, in their case.

None of that goes away. What changes is the interface on top, and what the platform must add so agents can use it safely.

Assistants, agents, and who owns them

They separate determinism from non-determinism, and an assistant from an agent:

• An assistant doesn’t act. You ask, it answers, perhaps with retrieved context.
• An agent gets a goal and capabilities, not a script. It runs a reasoning loop (observe, decide which tool to call, call it) until it reaches the goal. You can cap the number of loops, but you don’t define every path.

Their advice is to treat an agent like a new collaborator. You’d onboard a person with training material; for an agent, that material is a skill.

They split agents into two categories:

Building an agent is easy now: the programming language is English. The hard parts are mapping the business workflow the agent will run, and stopping every team from building agents with different frameworks and different ways of reaching tools. That is the same sprawl platforms already fixed for microservices and infrastructure as code.

An agent is just another template

Should you build a separate agentic platform? “It depends.” If you already have Backstage with blueprints, the first step is simply a new template that deploys an agent. An agent is another application on the platform.

Their sample Backstage adds four kinds of catalog entry:

• Agents, with relations to the other agents each can talk to, the integrations they use, and the MCP servers and skills they’re allowed.
• Approved MCP servers, so a developer can’t onboard any MCP server they like. The catalog is where the allow-list is enforced.
• Skills, the best practices for using those MCP servers to reach other systems.
• AI sources, covering both a RAG knowledge base built from existing docs (troubleshooting guides, runbooks) and agent memory that collects knowledge as the agent works.

Because of non-determinism, two more things need attention beyond “deploy it”: knowledge and identity and governance.

Knowledge: the context is the problem, not the model

Lucas cites the Spider 2.0 SQL benchmark: a model that scored around 90% on clean academic schemas dropped to roughly 58–70% on enterprise schemas. The cause is ambiguity in the data, not the model.

Most of what’s missing is tacit knowledge. A Terraform module or a Helm chart is knowledge made explicit. How to use the pipeline, which approvals a change needs, and how a team actually troubleshoots live in people’s heads and in Slack threads. The real work is mapping the business workflow an agent will run and extracting the tacit knowledge it needs.

There are two ways to get knowledge to a model:

Ontologies

Personal assistants already build a graph of your past interactions automatically. For production agents, you can define the ontology yourself. For a microservice, you might say the relations that matter are its owning team, its deploy and troubleshooting runbooks, and the approvals a change requires.

A defined structure pays off in two ways:

• Cost: the agent retrieves only the context it needs, so it spends fewer tokens and hallucinates less. If the agent stores how it solved a past incident (which observability tools, which docs), a similar incident needs fewer reasoning loops.
• Governance: it’s easy to check whether, say, the required approval for that service exists.

Identity: stop lending your credentials

It’s 3:12 a.m., and an agent finds the root cause and fixes it. Whose name appears in CloudTrail? Usually yours, because the agent borrowed your credentials. A production agent needs its own identity so every invocation and reasoning loop can be traced to it. The demo platform uses Keycloak; other identity providers would work.

Then there’s the intersection of access. If an agent may deploy to production but the SRE asking it may not, the agent should refuse. Because every production agent has an owner, it can escalate to that owner to approve a break-glass request.

The demo, which runs on a live cluster:

1. Logged in as Sam in Slack, they ask the agent to scale checkout to eight replicas. It does.
2. Langfuse shows the request, that it was allowed by an Open Policy Agent decision written in Rego, and that Sam requested it.
3. They ask it to list the pods in kube-system. The agent itself can read pods in any namespace, but Sam can’t, so it’s denied. The trace metadata shows why: the request was for a different namespace than Sam’s checkout-only rule allows.

Governance: static rules first, a judge for the gaps

A lack of governance and observability is what trips customers up most. “It’s never the agent’s fault”: it’s the agent’s owner or the person using it, and the trace is how you find out which.

Agents can work at different levels of autonomy:

“Agent prepares” is what they see most: read-only access to observability and the Kubernetes cluster, plus the ability to propose a fix as a pull request.

Fully autonomous is fine for narrow changes. An agent might auto-merge a scale-up because it touches no application logic. But if no rule considers cost, that auto-approved change could be expensive. So:

• Write everything you can as static guard rails, in OPA or a similar engine. Those are deterministic.
• Add an LLM as a judge to rate each change’s risk. The agent may be allowed to open and merge PRs, but the judge can flag a high-risk change you never wrote a rule for and send it to a human.

The architecture

• The Backstage catalog generates YAML definitions, stored in GitHub.
• Argo CD deploys to the cluster; nothing gets there unless it came from the repo.
• Agents run in the cluster, using Amazon Bedrock as the model provider and reaching MCP servers through agentgateway.
• Keycloak, OPA and Langfuse provide identity, policy and tracing.

The catalog stays the pointer that ties it all together. It narrows what an agent can do so the agent is left with judgement only where judgement is needed.

Q&A: keeping the knowledge graph fresh

Asked how they stop stale instructions in a knowledge graph from misleading an agent, Lucas separated understanding from instructions. Instructions belong in skills. As the knowledge graph grows from conversations, you curate it and graduate recurring patterns into skills. He runs a scheduled job that pulls patterns out of the graph and turns them back into skills.

Try it yourself

The companion repo is PacktPublishing/Agentic-AI-for-Platform-Engineering. Its labs build the platform step by step on one local kind cluster. They’re for learning only and deliberately simplified, not a production baseline. You need Docker, kind and kubectl to start. The later labs also need Git, the GitHub CLI, jq, Python 3, a GitHub token and Amazon Bedrock credentials (the Anthropic API is documented as an alternative).

1. Create the shared cluster

git clone https://github.com/PacktPublishing/Agentic-AI-for-Platform-Engineering
cd Agentic-AI-for-Platform-Engineering/00-cluster-setup
./setup-cluster.sh

This creates the kind cluster agentic-platform, installs Metrics Server (patched for kind’s self-signed kubelet certificates) and Argo CD v3.0.21. It’s safe to re-run. For the knowledge lab alone, SKIP_ARGOCD=1 ./setup-cluster.sh skips Argo CD.

How to check it worked: run ./verify.sh. It reports pass or fail for the cluster, Metrics Server, Argo CD and the host.docker.internal bridge that in-cluster agents use to reach Backstage on your machine. Also, kubectl get deploy -n kube-system metrics-server and kubectl get deploy -n argocd argocd-server should both show 1/1 ready.

2. Open Argo CD

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo
kubectl port-forward svc/argocd-server -n argocd 8080:443

How to check it worked: https://localhost:8080 shows the Argo CD login; sign in as admin with the printed password.

3. Work through the labs

Chapter 4 stands alone; chapters 5, 7 and 8 build on each other. Each lab’s README has its own steps and checks. Throughout, changes go branch → pull request → human review and merge → Argo CD, and cluster diagnostics stay read-only.

The OPA rules from the talk’s demo are in chapter 8, lab 2. roles.yaml grants each role a list of tools per environment: a viewer can read pods and logs in dev, staging and production but can’t create branches or pull requests. agent-tool-validation.rego denies by default and combines those grants with the agent’s profile, the application metadata, and the requested tool and arguments.

How to check it worked: once lab 2 is merged and synced, kubectl -n agent-platform get pods shows the OPA and agent runtime pods running, and the lab’s test prompts show allowed and denied decisions in Langfuse.

4. Tear down

cd 00-cluster-setup && ./teardown.sh

How to check it worked: kind get clusters no longer lists agentic-platform.

How it ties together

• Developers and agents increasingly use the platform through MCP, not the portal. The portal stays, but it’s no longer the only interface.
• An agent is another catalog template. The catalog also becomes the allow-list for MCP servers, skills and knowledge sources.
• Agents fail on missing context, mostly tacit knowledge. Use RAG for static knowledge, MCP for live data, and a defined ontology to keep retrieval small and cheap.
• Production agents need an owner and their own identity. They act with the intersection of their rights and the requester’s, enforced by OPA and recorded in Langfuse.
• Every change goes through Git: static policy first, an LLM judge for risk the rules missed, and a human in the loop for anything risky.

Sources: the talk on YouTube, the book Agentic AI for Platform Engineering and its companion repo.