Context Platform StackContext Platform StackContext Platform Stack
Four interdependent engineering layers that determine whether AI agents reach production or join the agent cemetery: Cloud Infrastructure, Platform Engineering, Context Engineering, and Intent Engineering.Quatro camadas interdependentes de disciplina de engenharia que determinam se agentes de IA chegam à produção ou engrossam o cemitério de agentes: Infraestrutura Cloud, Engenharia de Plataforma, Engenharia de Contexto e Engenharia de Intenção.Cuatro capas interdependientes de disciplina de ingeniería que determinan si los agentes de IA llegan a producción o engrosán el cementerio de agentes: Infraestructura Cloud, Ingeniería de Plataforma, Ingeniería de Contexto e Ingeniería de Intención.
The Agent Cemetery
Only 26% of enterprise AI agents built in Q4 2025 reached deployment — a drop of 16 percentage points from the previous quarter. More agents were shut down than launched. At the same time, 73% of CEOs reported that AI was delivering value to their organizations. That 47-percentage-point gap between executive confidence and deployment reality is not a technology problem. It is an engineering discipline problem.
The funnel is predictable. In a typical enterprise budget of $50M for AI initiatives, 42 POCs are funded in a fiscal year. Eleven reach internal pilot. Three reach production serving real traffic. One generates measurable revenue or cost reduction — 2.4% of the investment. Organizations working with a structured approach to the four layers observed a 62% deployment rate in 2025, compared to the 26% industry average. The difference is not the model or the tooling. It is layer discipline.
Why Pilots Fail in Production
Three root causes explain 80% of failures:
Infrastructure treated as commodity. Agentic workloads are stateful, noisy, and require tool selection at runtime. Running on “generic Kubernetes” works up to three agents. From thirty agents onward, it breaks predictably.
Context treated as a detail. “The agent will learn on its own” is the phrase that precedes failure. Context is an engineered artifact with three memory tiers, a token budget, and weekly human curation.
Intent treated as optional. No architecture survives “do your best” as a directive. Agents need an explicit hierarchy of trade-offs or they learn an implicit one — usually wrong.
A fourth factor compounds all three: agents benchmarked on bug-fix tasks are 7× easier to demonstrate than agents performing real feature work. Claude Opus 4.5 scores 74.4% on SWE-bench (bug fixes) and only 11.0% on FeatureBench (greenfield features). POCs built around bug-fix demos systematically overestimate production capability.
The Four-Layer Stack
The Context Platform Stack defines four interdependent layers, each with a distinct owner, a distinct metric, and a distinct governance conversation.
Layer 01 — Cloud and Infrastructure: Where agents run, at what real cost. Compute, GPU, Kubernetes, CNCF patterns, observability. The question this layer answers: where do agents run, and at what cost?
Layer 02 — Platform Engineering: What agents can access, and who governs it. IDP, golden paths, guardrails, per-agent RBAC, quotas, audit agent. The question: what can agents access?
Layer 03 — Context Engineering: What agents can know, when, and at what token cost. The ACE pattern, skills, three memory tiers (hot, warm, cold), MCP servers. The question: what can agents know?
Layer 04 — Intent Engineering: What agents must optimize, and in what trade-off hierarchy. CONSTITUTION.md, SDD with EARS syntax, intent debt, specification engineering. The question: what should agents optimize?
The layers are not independent. Each layer serves the one above and constrains the one below. Treating agents as microservices breaks this contract in all four directions — which is why so many pilots work perfectly in the lab and fail in production.
Layer 01: Infrastructure
The CNCF Working Group published a Cognitive Platform Engineering reference architecture in 2025 with four planes: the data plane (Kubernetes, GPU, containers), the intelligence plane (workload patterns, optimization), the control plane (OPA policy enforcement, scheduling, quotas), and the experience plane (developer portals, CLIs, dashboards). The Sense-Reason-Act loop closes without human intervention: workload changes, the intelligence plane observes, the platform adapts.
The cost anatomy of a production agent surprises most teams. 42% is compute (what everyone measures). The remaining 58% is invisible until the invoice: 28% inference tokens (often ignored), 15% memory and vector DB (grows linearly with use), 10% network and MCP proxies, and 5% observability — almost always underfunded. If your team tracks only compute, your TCO estimate is off by a factor of two.
At the pod level, a production agentic workload runs four containers, not one: the agent runtime (model, main loop, decision logic), an MCP sidecar (terminates MCP connections, enforces RBAC and token rate limits, emits audit trail), a context sidecar (hot memory layer, skills resolver, CONSTITUTION.md), and a telemetry sidecar (OTel collector, decision spans, MELT metrics). The pod topology is the first platform engineering decision that determines whether the agent will scale.
Layer 02: Platform Engineering
The agentic IDP has seven components. Only two differ from a standard developer IDP: an Agent API alongside the human portal, and per-agent RBAC alongside standard policy-as-code. Without those two additions, the IDP is good for humans and invisible to agents.
Per-agent RBAC means every agent carries a distinct SPIFFE SVID (cryptographic workload identity), and every resource permission is a policy in OPA. A summarizer-agent gets read access to the production database, call rights to the model, and a daily quota of 50K tokens. An sre-incident-agent gets emergency break-glass access with an approval gate on write operations. Mixing these permissions in a single agent — the “one-big-agent” anti-pattern — means the first incident compromises everything.
Layer 03: Context Engineering
Context engineering is not prompt engineering with more steps. Prompt engineering optimizes a single agent-model interaction; its scope is one API call, its artifact is a versioned text template, and its time horizon is minutes. Context engineering designs the complete knowledge surface of an agent over time; its scope is the system across hundreds of interactions, its artifact is a memory architecture with curated skills and MCP servers, and its time horizon is months.
The three memory tiers:
- Hot (~660 tokens): Always in context. CONSTITUTION.md, agent identity, inviolable principles, safety hooks. Updated only on deploy.
- Warm (~2,000 tokens per activated skill): Loaded on demand by the task classifier. Specialist skills, per-repository AGENTS.md, domain schemas. Curated manually by tech leads weekly.
- Cold (~1,500 tokens per query): Never pre-loaded. Retrieved via MCP server with per-agent RBAC applied. Corporate knowledge base, production data, code.
A well-engineered agent stays within roughly 4,160 tokens per invocation. A poorly engineered one loads everything into hot memory and pays 30,000 tokens per trivial task.
The ACE pattern (Artifacts + Context + Execution) was applied to a 108,247-line C# enterprise backend over 12 weeks (283 agent sessions, 2,801 user prompts). Results: −32% tokens per task (from 18K to 12.2K per invocation), −47% p95 latency (from 9.2s to 4.9s), and +18% task completion rate. The migration from monolithic context injection to ACE took three weeks — cheaper than the token savings in the first month.
A controlled experiment across 47 internal repositories showed that human-curated AGENTS.md reduced runtime −28.64% and token consumption −16.58%. LLM-generated AGENTS.md added +3.02% overhead. Auto-generated documentation documents the obvious and omits the critical — tacit team knowledge that only humans can identify.
Layer 04: Intent Engineering
Intent engineering operates at four levels. Most organizations invest only in level 01 (prompt writing, time horizon: minutes) and leave levels 02–04 implicit. The hierarchy is cumulative: level 04 only works if 01–03 are explicit.
- Level 01: Prompt writing
- Level 02: Context curation (skills, AGENTS.md, policies)
- Level 03: Intent design (CONSTITUTION.md, objective hierarchy, hooks)
- Level 04: Specification engineering (SDD with EARS, machine-testable contracts)
CONSTITUTION.md has five mandatory sections: Identity (who the agent is, scope, limits), Values and trade-offs (ordered objective hierarchy — “prefer X to Y, always”), Hard constraints (inviolable — “never do Z under any circumstances”), Protocols (procedures for recurring situations), and Escalation hooks (when the agent must stop and call a human).
Specification Driven Development with EARS (Easy Approach to Requirements Syntax, ISO/IEC/IEEE 29148) turns ambiguous requirements into machine-testable contracts. “The system should be resilient to network failures” becomes: When a network call fails 3 times in 60s, the system shall open circuit breaker. While circuit is open, the system shall serve cached responses for up to 30 seconds.
Intent debt measures the gap between what you said the agent should do and what it is actually doing. The formula: ID = Σ(Dᵢ × Sᵢ) — the sum of decision drift weighted by decision stake. An agent making 3 high-risk decisions per week, 12 medium-risk, and 80 low-risk decisions scores an intent debt of 5.0. Organizations that treat intent as post-facto documentation will spend the next decade debugging agents that optimized the wrong thing with extreme efficiency.
Maturity and the Path Forward
The five maturity stages are: Ad-hoc (isolated POCs, no policy, no memory, no audit), Tool-led (IDP purchased, some guardrails, but infra and context ignored), Layered (all four layers exist with named owners, implicit contracts), Contracted (explicit versioned contracts between layers, CONSTITUTION.md in Git, intent debt tracked weekly), and Self-tuning (the intelligence plane adjusts allocation automatically).
Approximately 64% of enterprises sit at Stage 02. The most expensive jump is 02 to 03, because it requires confronting the three layers that were ignored. Organizational maturity is the minimum of the four layers, not the best-performing one.
Starting on Monday
Five actions that require no new budget:
- Catalogue agents already in production. Most enterprises have more than they admit and fewer than they think.
- Measure the real cost of one agent across all five vectors for at least one week.
- Write the first CONSTITUTION.md for the most visible agent — 200 lines, five sections, committed to Git.
- Name the owner of each of the four layers. If there is no named person, the layer does not exist.
- Schedule a review in 90 days to measure intent debt. If you don’t come back to measure, nothing else matters.
The 30/60/90-day roadmap: days 1–30 establish baseline diagnosis (agent inventory, cost measurement, named owners, one pilot CONSTITUTION.md); days 31–60 make one agent fully observable (three-tier memory, per-agent RBAC via SPIFFE, MCP gateway, OTel decision spans); days 61–90 produce the first mature agent with measured intent debt and a replicable playbook. Four quarters from pilot to self-tuning platform. Start with the platform, not the agents.
O Cemitério de Agentes
Apenas 26% dos agentes de IA enterprise construídos no Q4 de 2025 chegaram ao deployment — uma queda de 16 pontos percentuais em relação ao trimestre anterior. Mais agentes foram desligados do que colocados em produção. Ao mesmo tempo, 73% dos CEOs afirmavam que a IA estava entregando valor para suas organizações. Esse gap de 47 pontos percentuais entre a confiança executiva e a realidade do deployment não é um problema de tecnologia. É um problema de disciplina de engenharia.
O funil é previsível. Em um orçamento enterprise típico de 50M USD para iniciativas de IA, 42 POCs são financiados em um ano fiscal. Onze chegam à fase de piloto interno. Três chegam à produção servindo tráfego real. Um gera receita ou redução de custo mensurável — 2,4% do investimento. Organizações que trabalham com uma abordagem estruturada para as quatro camadas observaram uma taxa de deployment de 62% em 2025, contra os 26% da média do setor. A diferença não é o modelo nem o tooling. É a disciplina de camada.
Por que Pilotos Travam Antes da Produção
Três causas raiz explicam 80% das falhas:
Infraestrutura tratada como commodity. Cargas agênticas são stateful, ruidosas e demandam escolha de tool em runtime. Rodar em “Kubernetes genérico” funciona até três agentes. A partir de trinta, quebra previsivelmente.
Contexto tratado como detalhe. “O agente vai aprender sozinho” é a frase que precede a falha. Contexto é artefato engenheirado, com três camadas de memória, orçamento de tokens e curadoria humana semanal.
Intenção tratada como opcional. Nenhuma arquitetura sobrevive a “faça o melhor que puder” como diretiva. Agentes precisam de hierarquia de trade-offs explícita ou aprendem uma implícita — geralmente errada.
Um quarto fator amplifica os três: agentes benchmarked em tarefas de bug fix são 7× mais fáceis de demonstrar do que agentes executando feature work real. O Claude Opus 4.5 atinge 74,4% no SWE-bench (bugs) e apenas 11,0% no FeatureBench (features greenfield). POCs construídos em torno de demos de bug fix superestimam sistematicamente a capacidade em produção.
A Pilha de Quatro Camadas
O Context Platform Stack define quatro camadas interdependentes, cada uma com owner distinto, métrica distinta e conversação de governança distinta.
Camada 01 — Cloud e Infraestrutura: Onde os agentes rodam, a que custo real. Compute, GPU, Kubernetes, padrões CNCF, observabilidade. A pergunta que esta camada responde: onde os agentes rodam, e a que custo?
Camada 02 — Engenharia de Plataforma: O que os agentes podem acessar, e quem governa. IDP, golden paths, guardrails, RBAC por agente, quotas, auditor agent. A pergunta: o que os agentes podem acessar?
Camada 03 — Engenharia de Contexto: O que os agentes podem saber, quando, e ao custo de quantos tokens. O padrão ACE, skills, três camadas de memória (hot, warm, cold), MCP servers. A pergunta: o que os agentes podem saber?
Camada 04 — Engenharia de Intenção: O que os agentes devem otimizar, e em que hierarquia de trade-offs. CONSTITUTION.md, SDD com sintaxe EARS, intent debt, specification engineering. A pergunta: o que os agentes devem otimizar?
As camadas não são independentes. Cada camada serve a de cima e restringe a de baixo. Tratar agentes como microserviços quebra esse contrato nas quatro direções — e é por isso que tantos pilotos funcionam perfeitamente no laboratório e falham em produção.
O modelo de quatro camadas tem uma defesa precisa. Fundir contexto e intenção gera drift: quando “o que o agente sabe” e “o que o agente quer” convivem no mesmo artefato, qualquer mudança de skill altera o comportamento esperado e ninguém sabe se é bug ou feature. Por outro lado, fragmentar infra e plataforma em cinco ou mais camadas dilui a responsabilidade sem ganho — para workloads agênticos, quem controla scheduling controla escolha de tool, e essa é uma decisão só.
Camada 01: Infraestrutura
O CNCF Working Group publicou em 2025 uma arquitetura de referência de Cognitive Platform Engineering com quatro planos: o data plane (Kubernetes, GPU, containers), o intelligence plane (padrões de workload, otimização), o control plane (enforcement OPA, scheduling, quotas) e o experience plane (portais de desenvolvedor, CLIs, dashboards). O loop Sense-Reason-Act fecha sem intervenção humana: o workload muda, o intelligence plane observa, a plataforma se adapta.
A anatomia de custo de um agente em produção surpreende a maioria dos times. 42% é compute (o que todos medem). Os outros 58% são invisíveis até o bill: 28% tokens de inferência (frequentemente ignorados), 15% memória e vector DB (cresce linear com o uso), 10% rede e proxies MCP, e 5% observabilidade — quase sempre underfunded. Se o seu time rastreia só compute, a estimativa de TCO está errada por um fator de dois.
No nível do pod, uma carga agêntica em produção roda quatro containers, não um: o agent runtime (modelo, loop principal, lógica de decisão), um sidecar MCP (termina conexões MCP, aplica RBAC e rate limiting de tokens, emite audit trail), um sidecar de contexto (hot memory layer, skills resolver, CONSTITUTION.md) e um sidecar de telemetria (OTel collector, decision spans, métricas MELT). A topologia do pod é a primeira decisão de platform engineering que define se o agente vai escalar.
Camada 02: Engenharia de Plataforma
O IDP agêntico tem sete componentes. Apenas dois diferem de um IDP de desenvolvedor padrão: uma Agent API ao lado do portal humano, e RBAC por agente ao lado das policies-as-code. Sem essas duas adições, o IDP é bom para humanos e invisível para agentes.
RBAC por agente significa que cada agente carrega um SPIFFE SVID distinto (identidade criptográfica de workload), e cada permissão de recurso é uma policy em OPA. Um summarizer-agent recebe acesso de leitura ao banco de produção, direito de chamada ao modelo e quota diária de 50K tokens. Um sre-incident-agent recebe acesso de break-glass emergencial com approval gate em operações de escrita. Misturar essas permissões em um único agente — o anti-padrão “one-big-agent” — significa que o primeiro incidente compromete tudo.
Os quatro pilares da plataforma — golden paths (da intenção à infraestrutura), guardrails (enforcement proativo), safety nets (resposta autônoma) e manual review (fricção estratégica) — existiam antes dos agentes. O que muda é que agora todos os quatro precisam considerar o agente como primeiro consumidor, não como afterthought de um portal humano.
Camada 03: Engenharia de Contexto
Engenharia de contexto não é prompt engineering com mais passos. Prompt engineering otimiza uma única interação agente-modelo; o seu escopo é uma chamada de API, o artefato é um template de texto versionado e o horizonte temporal são minutos. Engenharia de contexto desenha a superfície completa de conhecimento de um agente ao longo do tempo; o escopo é o sistema por centenas de interações, o artefato é uma arquitetura de memória com skills curadas e MCP servers, e o horizonte temporal são meses.
As três camadas de memória:
- Hot (~660 tokens): Sempre no contexto. CONSTITUTION.md, identidade do agente, princípios invioláveis, hooks de segurança. Atualizado só em deploy.
- Warm (~2.000 tokens por skill ativada): Carregado sob demanda pelo classificador de tarefa. Skills especialistas, AGENTS.md por repositório, schemas de domínio. Curadas manualmente por tech leads toda semana.
- Cold (~1.500 tokens por query): Nunca pré-carregado. Buscado via MCP server com RBAC por agente aplicado. Knowledge base corporativa, dados de produção, código.
Um agente bem engenheirado fica dentro de aproximadamente 4.160 tokens por invocação. Um mal engenheirado carrega tudo em hot memory e paga 30.000 tokens por tarefa trivial.
O padrão ACE (Artifacts + Context + Execution) foi aplicado a um backend enterprise em C# de 108.247 linhas ao longo de 12 semanas (283 sessões de agente, 2.801 prompts de usuário). Resultados: −32% tokens por tarefa (de 18K para 12,2K por invocação), −47% latência p95 (de 9,2s para 4,9s) e +18% taxa de conclusão de tarefas. A migração de injeção de contexto monolítico para ACE levou três semanas — mais barato do que o retorno em tokens no primeiro mês.
Um experimento controlado em 47 repositórios internos mostrou que AGENTS.md curado por humanos reduziu o runtime em −28,64% e o consumo de tokens em −16,58%. AGENTS.md gerado por LLM adicionou +3,02% de overhead. Documentação gerada automaticamente documenta o óbvio e omite o crítico — o conhecimento tácito do time que só humanos conseguem identificar.
Camada 04: Engenharia de Intenção
Engenharia de intenção opera em quatro níveis. A maioria das organizações investe só no nível 01 (prompt writing, horizonte temporal: minutos) e deixa os níveis 02–04 implícitos. A hierarquia é cumulativa: o nível 04 só funciona se 01–03 estiverem explícitos.
- Nível 01: Prompt writing
- Nível 02: Context curation (skills, AGENTS.md, policies)
- Nível 03: Intent design (CONSTITUTION.md, hierarquia de objetivos, hooks)
- Nível 04: Specification engineering (SDD com EARS, contratos testáveis por máquina)
O CONSTITUTION.md tem cinco seções obrigatórias: Identity (quem é o agente, escopo, limites), Values and trade-offs (hierarquia de objetivos ordenada — “prefira X a Y, sempre”), Hard constraints (invioláveis — “nunca faça Z, sob nenhuma circunstância”), Protocols (procedimentos para situações recorrentes) e Escalation hooks (quando o agente deve parar e chamar um humano).
Specification Driven Development com EARS (Easy Approach to Requirements Syntax, ISO/IEC/IEEE 29148, cunhado para a Rolls-Royce em 2009) transforma requisitos ambíguos em contratos testáveis por máquina. “O sistema deve ser resiliente a falhas de rede” se torna: Quando uma chamada de rede falhar 3 vezes em 60s, o sistema deverá abrir o circuit breaker. Enquanto o circuito estiver aberto, o sistema deverá servir respostas em cache por até 30 segundos.
Intent debt mede o gap entre o que você disse que o agente deve fazer e o que ele está fazendo. A fórmula: ID = Σ(Dᵢ × Sᵢ) — a soma do drift de decisão ponderado pelo risco da decisão. Um agente tomando 3 decisões de alto risco por semana, 12 de médio risco e 80 de baixo risco acumula um intent debt de 5,0. Organizações que tratam intenção como documentação pós-fato vão passar a próxima década debugando agentes que otimizaram a coisa errada de forma extremamente eficiente.
Maturidade e o Caminho à Frente
Os cinco estágios de maturidade são: Ad-hoc (POCs isolados, sem política, sem memória, sem auditoria), Tool-led (IDP comprado, alguns guardrails, mas infra e contexto ignorados), Layered (as quatro camadas existem com owners nomeados, contratos implícitos), Contracted (contratos explícitos e versionados entre camadas, CONSTITUTION.md no Git, intent debt rastreado semanalmente) e Self-tuning (o intelligence plane ajusta a alocação automaticamente).
Aproximadamente 64% das empresas estão no estágio 02. O salto mais caro é de 02 para 03, porque exige enfrentar as três camadas que foram ignoradas. A maturidade organizacional é o mínimo das quatro camadas, não a que tem melhor prática.
Por Onde Começar na Segunda-Feira
Cinco ações que não precisam de novo orçamento:
- Catalogue os agentes que já existem em produção. A maioria das empresas tem mais do que admite e menos do que acha.
- Meça o custo real de um agente nos cinco vetores por pelo menos uma semana.
- Escreva o primeiro CONSTITUTION.md para o agente mais visível — 200 linhas, cinco seções, commit no Git.
- Nomeie o owner de cada uma das quatro camadas. Se não houver pessoa nomeada, a camada não existe — existe wishful thinking.
- Marque uma reunião em 90 dias para medir o intent debt do agente que tiver CONSTITUTION.md. Se você não voltar a medir, nada do resto importa.
O roadmap de 30/60/90 dias: os dias 1–30 estabelecem o diagnóstico baseline (inventário de agentes, medição de custo, owners nomeados, um CONSTITUTION.md piloto); os dias 31–60 tornam um agente completamente observável (memória três camadas, RBAC por agente via SPIFFE, MCP gateway, OTel decision spans); os dias 61–90 produzem o primeiro agente maduro com intent debt medido e playbook replicável. Quatro trimestres do piloto à plataforma self-tuning. Comece pela plataforma, não pelos agentes.
El Cementerio de Agentes
Solo el 26% de los agentes de IA enterprise construidos en Q4 de 2025 llegaron a deployment — una caída de 16 puntos porcentuales respecto al trimestre anterior. Se desconectaron más agentes de los que se pusieron en producción. Al mismo tiempo, el 73% de los CEOs afirmaba que la IA estaba generando valor para sus organizaciones. Esa brecha de 47 puntos porcentuales entre la confianza ejecutiva y la realidad del deployment no es un problema tecnológico. Es un problema de disciplina de ingeniería.
El embudo es predecible. En un presupuesto enterprise típico de 50M USD para iniciativas de IA, se financian 42 POCs en un año fiscal. Once llegan a la fase de piloto interno. Tres llegan a producción sirviendo tráfico real. Uno genera ingresos o reducción de costos medible — el 2,4% de la inversión. Las organizaciones que trabajan con un enfoque estructurado en las cuatro capas observaron una tasa de deployment del 62% en 2025, frente al 26% del promedio sectorial. La diferencia no está en el modelo ni en las herramientas. Está en la disciplina de capa.
Por Qué los Pilotos Se Detienen Antes de Producción
Tres causas raíz explican el 80% de los fallos:
Infraestructura tratada como commodity. Las cargas de trabajo agénticas son stateful, ruidosas y requieren selección de herramientas en tiempo de ejecución. Ejecutar en “Kubernetes genérico” funciona hasta tres agentes. A partir de treinta, falla de forma predecible.
Contexto tratado como detalle. “El agente aprenderá solo” es la frase que precede al fallo. El contexto es un artefacto de ingeniería con tres capas de memoria, presupuesto de tokens y curación humana semanal.
Intención tratada como opcional. Ninguna arquitectura sobrevive a “haz lo mejor que puedas” como directiva. Los agentes necesitan una jerarquía explícita de trade-offs o aprenden una implícita, generalmente incorrecta.
Un cuarto factor amplifica los tres: los agentes evaluados en tareas de corrección de bugs son 7 veces más fáciles de demostrar que los agentes que realizan trabajo real de features. Claude Opus 4.5 alcanza el 74,4% en SWE-bench (bugs) y solo el 11,0% en FeatureBench (features greenfield). Los POCs construidos en torno a demos de corrección de bugs sobreestiman sistemáticamente la capacidad en producción.
El Stack de Cuatro Capas
El Context Platform Stack define cuatro capas interdependientes, cada una con un responsable distinto, una métrica distinta y una conversación de gobernanza distinta.
Capa 01 — Cloud e Infraestructura: Dónde ejecutan los agentes, a qué costo real. Compute, GPU, Kubernetes, patrones CNCF, observabilidad. La pregunta que responde esta capa: ¿dónde ejecutan los agentes y a qué costo?
Capa 02 — Ingeniería de Plataforma: A qué pueden acceder los agentes y quién lo gobierna. IDP, golden paths, guardrails, RBAC por agente, cuotas, agente auditor. La pregunta: ¿a qué pueden acceder los agentes?
Capa 03 — Ingeniería de Contexto: Qué pueden saber los agentes, cuándo y a qué costo en tokens. El patrón ACE, skills, tres capas de memoria (hot, warm, cold), servidores MCP. La pregunta: ¿qué pueden saber los agentes?
Capa 04 — Ingeniería de Intención: Qué deben optimizar los agentes y en qué jerarquía de trade-offs. CONSTITUTION.md, SDD con sintaxis EARS, intent debt, ingeniería de especificaciones. La pregunta: ¿qué deben optimizar los agentes?
Las capas no son independientes. Cada capa sirve a la superior y restringe a la inferior. Tratar a los agentes como microservicios rompe este contrato en las cuatro direcciones, que es por qué tantos pilotos funcionan perfectamente en el laboratorio y fallan en producción.
El modelo de cuatro capas tiene una defensa precisa. Fusionar contexto e intención genera drift: cuando “lo que el agente sabe” y “lo que el agente quiere” conviven en el mismo artefacto, cualquier cambio en las skills altera el comportamiento esperado y nadie sabe si es un bug o una feature. Por otro lado, fragmentar la infraestructura y la plataforma en cinco o más capas diluye la responsabilidad sin beneficio — para cargas de trabajo agénticas, quien controla el scheduling controla la selección de herramientas, y esa es una sola decisión.
Capa 01: Infraestructura
El CNCF Working Group publicó en 2025 una arquitectura de referencia de Cognitive Platform Engineering con cuatro planos: el data plane (Kubernetes, GPU, contenedores), el intelligence plane (patrones de workload, optimización), el control plane (enforcement OPA, scheduling, cuotas) y el experience plane (portales de desarrollador, CLIs, dashboards). El loop Sense-Reason-Act se cierra sin intervención humana: el workload cambia, el intelligence plane observa, la plataforma se adapta.
La anatomía de costos de un agente en producción sorprende a la mayoría de los equipos. El 42% es compute (lo que todos miden). El 58% restante es invisible hasta que llega la factura: 28% tokens de inferencia (frecuentemente ignorados), 15% memoria y vector DB (crece linealmente con el uso), 10% red y proxies MCP, y 5% observabilidad — casi siempre infradotada. Si tu equipo solo rastrea compute, la estimativa de TCO está desviada por un factor de dos.
A nivel de pod, una carga agéntica en producción ejecuta cuatro contenedores, no uno: el agent runtime (modelo, bucle principal, lógica de decisión), un sidecar MCP (termina conexiones MCP, aplica RBAC y rate limiting de tokens, emite audit trail), un sidecar de contexto (capa de hot memory, resolvedor de skills, CONSTITUTION.md) y un sidecar de telemetría (colector OTel, decision spans, métricas MELT). La topología del pod es la primera decisión de platform engineering que determina si el agente escalará.
Capa 02: Ingeniería de Plataforma
El IDP agéntico tiene siete componentes. Solo dos difieren de un IDP de desarrollador estándar: una Agent API junto al portal humano, y RBAC por agente junto a las políticas estándar como código. Sin estas dos adiciones, el IDP es bueno para humanos e invisible para los agentes.
RBAC por agente significa que cada agente lleva un SPIFFE SVID distinto (identidad criptográfica de workload), y cada permiso de recurso es una política en OPA. Un summarizer-agent obtiene acceso de lectura a la base de datos de producción, permisos de llamada al modelo y una cuota diaria de 50K tokens. Un sre-incident-agent obtiene acceso de break-glass de emergencia con un approval gate en operaciones de escritura. Mezclar estos permisos en un solo agente — el anti-patrón “one-big-agent” — significa que el primer incidente compromete todo.
Los cuatro pilares de la plataforma — golden paths (de la intención a la infraestructura), guardrails (enforcement proactivo), safety nets (respuesta autónoma) y manual review (fricción estratégica) — existían antes que los agentes. Lo que cambia es que ahora los cuatro necesitan considerar al agente como primer consumidor, no como un añadido posterior a un portal humano.
Capa 03: Ingeniería de Contexto
La ingeniería de contexto no es prompt engineering con más pasos. El prompt engineering optimiza una única interacción agente-modelo; su alcance es una llamada a la API, el artefacto es una plantilla de texto versionada y el horizonte temporal son minutos. La ingeniería de contexto diseña la superficie completa de conocimiento de un agente a lo largo del tiempo; su alcance es el sistema en cientos de interacciones, el artefacto es una arquitectura de memoria con skills curadas y servidores MCP, y el horizonte temporal son meses.
Las tres capas de memoria:
- Hot (~660 tokens): Siempre en contexto. CONSTITUTION.md, identidad del agente, principios inviolables, hooks de seguridad. Se actualiza solo en deploy.
- Warm (~2.000 tokens por skill activada): Cargada bajo demanda por el clasificador de tareas. Skills especialistas, AGENTS.md por repositorio, esquemas de dominio. Curadas manualmente por tech leads semanalmente.
- Cold (~1.500 tokens por query): Nunca precargada. Recuperada vía servidor MCP con RBAC por agente aplicado. Base de conocimiento corporativa, datos de producción, código.
Un agente bien diseñado se mantiene dentro de aproximadamente 4.160 tokens por invocación. Uno mal diseñado carga todo en hot memory y paga 30.000 tokens por una tarea trivial.
El patrón ACE (Artifacts + Context + Execution) fue aplicado a un backend enterprise en C# de 108.247 líneas durante 12 semanas (283 sesiones de agente, 2.801 prompts de usuario). Resultados: −32% tokens por tarea (de 18K a 12,2K por invocación), −47% latencia p95 (de 9,2s a 4,9s) y +18% tasa de completación de tareas. La migración de inyección de contexto monolítica a ACE tomó tres semanas — más barato que el ahorro en tokens del primer mes.
Un experimento controlado en 47 repositorios internos mostró que AGENTS.md curado por humanos redujo el tiempo de ejecución en −28,64% y el consumo de tokens en −16,58%. AGENTS.md generado por LLM añadió +3,02% de overhead. La documentación generada automáticamente documenta lo obvio y omite lo crítico — el conocimiento tácito del equipo que solo los humanos pueden identificar.
Capa 04: Ingeniería de Intención
La ingeniería de intención opera en cuatro niveles. La mayoría de las organizaciones solo invierte en el nivel 01 (prompt writing, horizonte temporal: minutos) y deja los niveles 02–04 implícitos. La jerarquía es acumulativa: el nivel 04 solo funciona si los niveles 01–03 son explícitos.
- Nivel 01: Prompt writing
- Nivel 02: Context curation (skills, AGENTS.md, políticas)
- Nivel 03: Intent design (CONSTITUTION.md, jerarquía de objetivos, hooks)
- Nivel 04: Specification engineering (SDD con EARS, contratos verificables por máquina)
El CONSTITUTION.md tiene cinco secciones obligatorias: Identity (quién es el agente, alcance, límites), Values and trade-offs (jerarquía de objetivos ordenada — “prefiere X a Y, siempre”), Hard constraints (inviolables — “nunca hagas Z bajo ninguna circunstancia”), Protocols (procedimientos para situaciones recurrentes) y Escalation hooks (cuándo el agente debe detenerse y llamar a un humano).
Specification Driven Development con EARS (Easy Approach to Requirements Syntax, ISO/IEC/IEEE 29148, desarrollado para Rolls-Royce en 2009) transforma requisitos ambiguos en contratos verificables por máquina. “El sistema debe ser resiliente a fallos de red” se convierte en: Cuando una llamada de red falle 3 veces en 60s, el sistema deberá abrir el circuit breaker. Mientras el circuito esté abierto, el sistema deberá servir respuestas en caché durante hasta 30 segundos.
Intent debt mide la brecha entre lo que dijiste que el agente debe hacer y lo que está haciendo realmente. La fórmula: ID = Σ(Dᵢ × Sᵢ) — la suma del drift de decisión ponderado por el riesgo de la decisión. Un agente que toma 3 decisiones de alto riesgo por semana, 12 de riesgo medio y 80 de bajo riesgo acumula un intent debt de 5,0. Las organizaciones que tratan la intención como documentación posterior pasarán la próxima década depurando agentes que optimizaron lo incorrecto con extrema eficiencia.
Madurez y el Camino a Seguir
Los cinco estadios de madurez son: Ad-hoc (POCs aislados, sin política, sin memoria, sin auditoría), Tool-led (IDP adquirido, algunos guardrails, pero infra y contexto ignorados), Layered (las cuatro capas existen con responsables nombrados, contratos implícitos), Contracted (contratos explícitos y versionados entre capas, CONSTITUTION.md en Git, intent debt rastreado semanalmente) y Self-tuning (el intelligence plane ajusta la asignación automáticamente).
Aproximadamente el 64% de las empresas se encuentra en el estadio 02. El salto más costoso es de 02 a 03, porque exige enfrentar las tres capas que fueron ignoradas. La madurez organizacional es el mínimo de las cuatro capas, no la que tiene la mejor práctica.
Por Dónde Empezar el Lunes
Cinco acciones que no requieren presupuesto nuevo:
- Inventariar los agentes que ya existen en producción. La mayoría de las empresas tiene más de los que admite y menos de los que cree.
- Medir el costo real de un agente en los cinco vectores durante al menos una semana.
- Escribir el primer CONSTITUTION.md para el agente más visible — 200 líneas, cinco secciones, commit en Git.
- Nombrar el responsable de cada una de las cuatro capas. Si no hay una persona nombrada, la capa no existe, solo existe wishful thinking.
- Programar una revisión en 90 días para medir el intent debt del agente que tenga CONSTITUTION.md. Si no vuelves a medir, nada de lo demás importa.
El roadmap de 30/60/90 días: los días 1–30 establecen el diagnóstico baseline (inventario de agentes, medición de costos, responsables nombrados, un CONSTITUTION.md piloto); los días 31–60 hacen que un agente sea completamente observable (memoria en tres capas, RBAC por agente vía SPIFFE, MCP gateway, OTel decision spans); los días 61–90 producen el primer agente maduro con intent debt medido y un playbook replicable. Cuatro trimestres del piloto a la plataforma self-tuning. Empieza por la plataforma, no por los agentes.
Start with the platform, not the agents. Comece pela plataforma, não pelos agentes. Comience por la plataforma, no por los agentes.
Building the future of software development with AI and Agentic DevOps.