Capítulo 20 — Da prática individual à organização agêntica

Escala muda o problema

Um único desenvolvedor usando um agente pode sobreviver com muita memória informal.

Uma organização não.

Quando aumentam:

• número de agentes;
• número de pessoas;
• número de produtos;
• número de missões paralelas;

o problema deixa de ser apenas “o agente escreve bom código?”.

Passa a ser:

como manter coerência, responsabilidade e custo sob controle em escala?

Hassan argumenta que, quando humanos, agentes e missões crescem em paralelo, falhas passam a ser também problemas de orquestração, exigindo platform, coordination, capability e trust engineering. ¹

Da ferramenta ao sistema operacional organizacional

Comprar uma ferramenta não cria uma organização agêntica.

É necessário construir:

• práticas;
• artefatos;
• policies;
• ownership;
• platform boundaries;
• observability;
• qualification;
• recovery.

O ativo central deixa de ser a licença.

Passa a ser o sistema de engenharia que limita e evidencia a mudança.

1-to-1 não escala para sempre

No modo inicial:

1 humano ↔ 1 agente

O humano consegue acompanhar quase tudo.

Depois:

1 humano ↔ N agentes

E, em escala:

N humanos ↔ N agentes

Hassan et al. descrevem esse cenário como exigindo command environment, governança multirrole, revisão orientada por evidências e consulta multifuncional. ²

O novo gargalo é atenção

Quanto mais barato fica gerar mudança, mais cara fica a decisão.

Humanos precisam concentrar atenção em:

• intenção;
• risco;
• trade-offs;
• aprovação;
• exceções;
• aprendizagem.

A plataforma deve reduzir trabalho de arqueologia.

Organizational maturity

método deste livro:

Podemos representar maturidade em cinco níveis.

M0 — Ad hoc

• chat;
• copy/paste;
• pouca rastreabilidade;
• permissões amplas;
• revisão informal.

M1 — Structured individual

• Specs;
• tests;
• Git;
• basic CI;
• manual approvals.

M2 — Governed team

• shared policies;
• evidência packs;
• capability boundaries;
• explicit ownership;
• recovery paths.

M3 — Platformed organization

• standardized workbenches;
• reusable gates;
• central observability;
• qualification;
• cost tracking;
• policy enforcement.

M4 — Adaptive organization

• learning loops;
• progressive delegation;
• requalification;
• automated containment;
• organization-wide evidência reuse.

A escala não deve ser tratada como benchmark universal.

É uma ferramenta de diagnóstico do método deste livro.

Maturity não é número de agentes

Ter cem agentes não significa maturidade.

Pode significar apenas cem fontes de mudança paralela.

Maturidade aparece quando throughput cresce sem perder:

• traceability;
• recoverability;
• policy compliance;
• decision quality.

Ownership

Toda superfície importante precisa de owner.

Exemplos:

• service;
• policy;
• runbook;
• qualification suite;
• release pipeline;
• contexto pack;
• agent role.

Sem ownership, problemas cruzam equipes sem autoridade clara para resolver.

Platform boundary

A plataforma deve definir o que é comum e o que continua local.

Comum pode incluir:

• identity;
• secrets;
• CI templates;
• evidência capture;
• logging;
• policy engine;
• agent registry;
• cost telemetry.

Local pode incluir:

• domain rules;
• acceptance criteria;
• business risk;
• product-specific ferramentas.

Paved road

método deste livro:

A organização deveria oferecer um caminho seguro e barato por padrão.

Exemplo:

create service
  ↓
standard repo
  ↓
CI template
  ↓
observability
  ↓
secrets
  ↓
deploy
  ↓
rollback

Se o caminho correto for difícil, as equipes criarão atalhos.

Platform não pode virar prisão

Standardization demais pode bloquear casos legítimos.

Por isso, paved road precisa de:

• escape hatch;
• exception process;
• evidência requirement;
• owner;
• expiration/revisão.

Governance

García trata governance como prática transversal para privacy, safety, security, accountability, transparency, fairness e human oversight. ³

Governança, portanto, não é um gate final.

Ela atravessa a stack.

Policy as code

Quando possível, policies obrigatórias deveriam ser executáveis.

Exemplos:

• branch protection;
• deployment permission;
• secret scanning;
• data-access rule;
• approval requirement.

Texto continua útil para rationale.

Enforcement deve viver onde pode ser verificado.

Human oversight

Human oversight não significa humano aprovando cada ação.

Pode significar:

• definir boundaries;
• aprovar high-risk changes;
• revisar exceptions;
• acompanhar evidência;
• ajustar policies.

O objetivo é usar atenção humana onde julgamento é realmente necessário.

Capability engineering

Uma organização precisa saber:

• o que cada agente pode fazer;
• com quais ferramentas;
• sob quais policies;
• com que evidência;
• em quais domínios.

Capability não deve ser assumida a partir do nome do modelo.

Agent registry

método deste livro:

Um registro pode conter:

agent_id
role
model/provider
allowed_tools
qualification
risk_tier
cost_profile
owner
last_requalified

Isso torna capability visível.

Role-based agents

Agentes podem ser especializados por função:

• implementation;
• revisão;
• test generation;
• security;
• migration;
• documentation.

Separação pode melhorar boundaries e independência de verificação.

Tool/vendor portability

Dependência excessiva de provider pode concentrar risco.

A organização precisa distinguir:

• método;
• interface;
• provider;
• model.

O método deve sobreviver a troca de ferramenta.

Portable artifacts

Quanto mais o sistema depende de artefatos abertos e versionados, menor o lock-in conceitual.

Exemplos:

• Markdown;
• JSON;
• Git;
• OpenAPI;
• standard logs;
• OCI images.

Portability não significa lowest common denominator

Podemos usar recursos específicos do fornecedor.

Mas devemos saber onde a dependência existe e o custo de troca.

Cost of intelligence

Agentes consomem recursos.

Custos podem incluir:

• tokens;
• model inference;
• ferramenta calls;
• compute;
• storage;
• retries;
• human revisão.

Cost precisa ser observado junto com value e risk.

Cost por outcome

método deste livro:

Melhor que medir apenas tokens:

cost per accepted change
cost per resolved incident
cost per successful task

Isso aproxima economics da unidade de valor.

Cheap generation, expensive verification

Em algumas tarefas, gerar alternativas pode ser barato.

Verificar cada uma pode dominar o custo.

Por isso, economics também influencia architecture de revisão.

Resource budgets

Podemos definir:

• max model cost;
• max parallel agents;
• max runtime;
• max retries;
• max contexto size.

Budget não precisa bloquear tudo.

Pode alertar, degradar ou escalar.

Fleet observability

A organização precisa responder:

• quantos agentes estão ativos?
• onde falham?
• quanto custam?
• onde humans intervêm?
• quais policies são mais violadas?

Isso desloca observability do serviço para a fleet.

Command environment

Hassan et al. propõem um ambiente humano capaz de coordenar múltiplos agentes, preservar accountability e suportar revisão baseado em evidência. ²

No método deste livro, o Project Command Center é uma implementação concreta dessa necessidade mais geral.

Project Command Center como implementação

Ele pode consolidar:

• projects;
• status;
• Change Episodes;
• evidência;
• risk;
• next action;
• release/runtime state.

Não reivindicamos novidade conceitual para command centers.

Nosso diferencial é a implementação longitudinal observável.

Organizational Evidence Map

Artefato operacional deste capítulo.

Exemplo:

Surface	Owner	Policy	Evidence	Recovery	Cost
agent role	platform	qualification	suite run	demote	model
deploy	SRE	approval	CI/release	rollback	compute
data access	security	RBAC	audit log	revoke	—
contexto	product	lineage	version	rollback	tokens

Maturity/Evidence Map

método deste livro:

Para cada capability organizacional, registrar:

• current maturity;
• target;
• owner;
• missing evidência;
• next control.

Isso evita roadmap baseado apenas em features.

O que automatizar

Automatize quando:

• regra é repetível;
• failure condition é detectável;
• rollback é conhecido;
• decisão não exige julgamento contextual alto.

Exemplos:

• lint;
• build;
• secret scan;
• rollback automático em threshold claro.

O que manter humano

Mantenha decisão humana quando envolve:

• trade-off estratégico;
• ética;
• risco legal material;
• mudança irreversível relevante;
• ambiguous intent;
• exception de policy.

Automation boundary

A pergunta correta não é:

“dá para automatizar?”

É:

“temos evidência, containment e authority para automatizar com segurança?”

Organizational autonomy

No nível organizacional, autonomia deixa de ser uma decisão isolada de tarefa e vira propriedade governada da plataforma.

O gate deste capítulo é:

autonomia organizacional só expande quando platform, policy, capability evidência, runtime health, cost visibility e recovery acompanham.

Isso é método deste livro.

A diferença para os capítulos anteriores é de escala: não estamos decidindo se uma mudança específica pode avançar, mas se um tipo de agente/workflow pode receber um envelope maior de atuação em vários contextos.

Progressive delegation em escala

Podemos começar com:

• approvals frequentes;
• budgets baixos;
• limited ferramentas.

E expandir quando evidência demonstra:

• low failure rate;
• clean provenance;
• successful recovery;
• stable cost.

Anti-pattern: licenças antes de operating model

Comprar muitas ferramentas antes de definir boundaries gera fragmentação.

Problemas comuns:

• cada equipe configura de um jeito;
• credentials espalhadas;
• policies diferentes;
• evidência incompatível.

Anti-pattern: centralizar tudo

Uma platform team não conhece todos os domínios.

Centralize infrastructure e governance transversal.

Mantenha domain decisions perto de quem conhece o produto.

Anti-pattern: cost sem value

Reduzir tokens pode aumentar retrabalho.

Economics precisa considerar outcome.

Anti-pattern: provider como architecture

Se todo workflow depende de uma UI específica, trocar fornecedor pode exigir reconstruir o processo inteiro.

Artefatos e boundaries reduzem esse risco.

Anti-pattern: governance só em documento

Policy sem enforcement, observability ou audit trail vira intenção.

Anti-pattern: automação irreversível

Quanto maior a autonomia, mais importantes:

• containment;
• rollback;
• kill switch;
• audit.

Organizational adoption

Adoção sustentável combina:

• training;
• platform;
• standards;
• pilot projects;
• evidência;
• feedback loops.

Não é necessário migrar tudo de uma vez.

Pilot → evidência → scale

método deste livro:

bounded pilot
  ↓
evidência
  ↓
policy refinement
  ↓
platformization
  ↓
wider adoption

Maturity revisão

Periodicamente, revisar:

• autonomy;
• failure patterns;
• cost;
• human intervention;
• recovery;
• evidência quality.

Essas dimensões também serão usadas no fechamento longitudinal do livro.

O caso longitudinal como moat

Como fontes contemporâneas já cobrem grande parte da arquitetura conceitual, o diferencial defensável deste livro está na execução documentada.

O caso precisa mostrar:

• Specs reais;
• commits;
• CI;
• incidents;
• recovery;
• Change Episodes;
• evolution do PCC.

O método ganha valor quando pode ser auditado.

Rumo à conclusão

A Parte V fecha uma cadeia única:

Observe
  ↓
Recover
  ↓
Learn
  ↓
Scale

Operations torna comportamento visível. Recovery limita dano e restaura estado aceitável. Learning transforma incidente em mudança durável. Organization governa esse ciclo quando ele deixa de caber na cabeça de uma única pessoa ou equipe.

Depois de percorrer Intent → Learning, resta sintetizar o princípio geral:

a unidade de valor não é código gerado. É mudança confiável.

O próximo capítulo fecha o livro: Menos sintaxe, mais responsabilidade.

Fronteira de confiança

Em escala, trust boundaries existem entre equipes, agentes, providers, platforms, dados e produção. A organização precisa declarar ownership, authority e access boundaries; centralização sem boundaries cria blast radius organizacional.

Evidência exigida

Expansão de autonomia deve ser sustentada por evidência de capability, policy compliance, delivery quality, runtime health, recovery e custo. Número de agentes ou volume de código não constitui maturity evidência.

Rollback e recuperação

Organizational recovery inclui revogar permissões, reduzir autonomy envelopes, trocar provider, desabilitar workflows e retornar policies/configuration a estados anteriores. Portability e versionamento são também mecanismos de recovery.

Proveniência das fontes

Rastreabilidade deste capítulo:

• CLM-068 — Hassan et al., ACE para coordenação 1-to-N/N-to-N, multi-role governance, evidência revisão e capability/cost management;
• CLM-069 — Hassan, team scale exige platform/coordination/capability/trust engineering;
• CLM-070 — García, governance como prática transversal de privacy, safety, security, accountability, transparency, fairness e human oversight.

Maturity model M0–M4, Organizational Evidence Map, cost-per-outcome, Agent Registry e Pilot → Evidence → Scale são método deste livro.

Jayaratchagan, Liao e Ford permanecem fonte limitada e não foram usados como autoridade factual.

Fontes de acesso limitado não foram usadas como autoridade factual neste capítulo.

Recursos complementares

Recursos relacionados:

• Organizational Maturity Map;
• Organizational Evidence Map;
• Agent Registry template;
• cost-per-outcome worksheet;
• platform-boundary canvas;
• automation-boundary checklist;
• futura visualização PCC de maturity, fleet health, evidência e cost.

---

Footnotes

1. Ahmed E. Hassan, Agentic Software Engineering (2026), The Fool’s Paradise, p. 360. Rastreabilidade interna: CLM-069. ↩

2. Hassan et al., Agentic Software Engineering: Foundational Pillars and a Research Roadmap, 4.3.1 A New Workbench for the Human Developer: The ACE, p. 12. Rastreabilidade interna: CLM-068. ↩ ↩²

3. Boni García, Context Engineering (MEAP, 2026), 1.1.2 The context engineering stack — Governance, p. 10. Rastreabilidade interna: CLM-070. ↩