Agentic Leadership, Part 1: The Question No One Was Asking
In early 2026, the best engineers at KYP were closing 8 pull requests per day.
Not per week. Per day.
The best engineering organizations in the world average one PR per engineer per day. Our best professionals were 8 times above that. Without overtime. With more clarity than before.
When we needed to explain how this was possible, we realized the answer was uncomfortable. It wasn’t about tools. It was about a different question — one that most organizations still avoid asking.
The Wrong Conversation
There’s a scene that repeats in almost every tech company today. We’ve heard it dozens of times — in leadership meetings, at innovation events, in product alignments.
The question is always the same: “Which AI tool are the engineers using?”
Copilot or Cursor? Fine-tuning on the internal codebase? Private deployment for compliance? These are legitimate questions. They’re also equivalent to asking in 2010 which smartphone the company should adopt — and thinking that solved digital transformation.
The question no one was asking — and that we forced ourselves to answer — was this: if AI agents can already do a significant portion of the work, what exactly justifies the existence of a technology organization the way we know it?
It’s not a comfortable question. Exactly why it matters.
In April 2026, the world’s largest technology platforms began answering this question publicly. When that happens, the window of differentiation isn’t in the tool — it’s in how soon you internalized the operating model that makes the tool useful. Tools converge. Operating models don’t.
What Changes When the Agent Enters
When we started running real AI agents — autonomous code agents, AI-powered data pipelines, LLMs integrated into operational workflows — we discovered something not in any model benchmark.
The bottleneck wasn’t the agent’s capability. It was what surrounded it.
Unclear responsibility. Undocumented context. Undefined success criteria. No rollback plan.
Here’s what changes everything: a human in a disorganized environment asks, infers, negotiates. They identify ambiguity and signal it. They cover the gap with judgment. Sometimes poorly, but they cover it.
An agent doesn’t do that. It hallucinates.
And confident hallucination is different from declared error. It travels. Passes code review, traverses the pipeline, reaches the customer — and only reveals itself when the cost has already been paid by someone who didn’t make the decision to leave context disorganized.
The agents were ready. The organization was not.
The Decision
We could have adopted the tools, monitored adoption metrics, and called it transformation. We could have centralized everything in a dedicated team isolated from the rest of engineering.
We didn’t.
KYP operates within a larger ecosystem: CERC has an AI Center of Excellence with which we regularly exchange information and best practices. But building KYP’s operating model required our own solutions — adapted to the specificities of the data business and the technologies we use here. What works in other contexts doesn’t always serve when you’re dealing with ingestion pipelines at scale, analytical models in production, and critical financial market infrastructure.
The central decision was different: dedicate senior people to this agenda.
Not as a separate team. As distributed responsibility. KYP’s most experienced engineers stopped treating AI agent adoption as a parallel task and began treating it as central to engineering work. This had a real cost — these people left immediate projects to invest in something whose return wasn’t obvious in the quarter.
This meant reviewing our entire development structure.
Sprints, delivery pace, definition of done criteria, code review processes — everything was re-examined with a different question: was this process designed for a world where only humans write code? In most cases, the answer was yes. And a process designed only for humans doesn’t accommodate an agent well.
The process is embedded alongside all teams.
There’s no group of specialists who “do AI” while the rest do normal engineering. Each squad has the automation agenda as part of their regular backlog. The question we ask systematically in any refinement is: is this repetitive? If so, it’s an automation opportunity.
Every repetitive activity is treated as automation debt. Test generation, API documentation, code compliance review, observability alerts, new service onboarding — none of these are seen as inevitable work anymore. They’re candidates to be done by agents, with engineers defining criteria and validating results.
The right question isn’t how to use AI. It’s what kind of organization you need to be to work with it — and who, within that organization, will carry the weight of transition when the answer takes time to arrive.
What we describe here is not a completed project. It’s a model under construction, tested under real pressure. In the next articles of this series, we’ll detail how this model translates into concrete decisions about architecture, process, and leadership.
KYP is CERC’s data business unit, which operates the infrastructure of the Brazilian financial market for receivables registration — a system where the consequences of error are measured in financial system stability, not sprint velocity.
This series was written by Sandor Caetano, Lucio Passos, and Juliano Pereira — technology leaders at KYP building the organizational infrastructure for native AI engineering.