Death by a Thousand Handoffs

I. The era of AI driven efficiency.(?)

Building software in the era of AI is an incredibly fun experience. What used to take weeks to months in agonizing planning sessions can now be condensed into a matter of days using a variety of shiny new tools. However, are we so sure that these tools are actually driving efficiency?

Take development of the most unglamorous feature in enterprise software: a data table. Filter the results, click a row to open the entity page, review the record, navigate back.

Here is how that screen actually got built in my past life. I suspect it will sound familiar.

I prototyped the interaction in Vercel's v0 until the flow felt right. I took my prompt to ChatGPT and decomposed it into requirements for a PRD. Designers replicated everything in Figma. Engineers reviewed the PRD and drew up engineering design documents based on their knowledge of our systems. Those became a set of Jira issues. At the end of the line, an agent does all of the implementation for you. It’s all done in a manner of days.

Sounds efficient, right? Let’s dig a little deeper…

II. Context Evaporated

Every handoff in that process dropped context the agent could use:

1. The prototype knew the intent. The v0 build encoded exactly how the interaction should feel: instant return, no refetch, state intact. The agent never sees it.
2. The PRD knew the why. The business rules and edge cases lived in a ChatGPT session and a doc three tools upstream. The agent gets two sentences.
3. The design doc knew the how. An engineer already reasoned about caching strategy and invalidation. The ticket carries the conclusion, but sees none of the reasoning.

Notice that no one in this story did anything wrong. Every step was diligent. The PRD was thorough, the design doc was thoughtful, the ticket was well written by the standards of tickets. The loss is structural. The workflow was designed to move work forward, not to move context forward, and agents can only act on the context that arrives.

III. The Smartest Teammate Outside the Room

Here is the strange part. The agent at the end of that line is the most knowledgeable engineer your organization has ever had access to. It has absorbed decades of data-fetching patterns, every flavor of state management and client-side routing, and every failure mode these systems have ever exhibited in the wild. It types faster than your whole team combined and never gets tired.

And yet think about how we treat it compared to any human engineer. An engineer sits in the planning meetings. They see the prototype, read the PRD, absorb the design doc, and soak up context through standups, code review, and a hundred Slack threads. By the time they touch the feature, they know why it exists and what "done" actually means.

The agent gets none of that. It joins the project at the very last step, receives a two-sentence ticket, and is expected to infer everything the room already knows. So not only is it lacking context, but it never had the opportunity to challenge any of the assumptions in the decision making process.

No organization would do that with their engineers, why are agents any different?

IV. A Seat in the Room

The market's instinct is to wait for a smarter teammate. Better agents, better models, better prompts. But no amount of talent compensates for being locked out of the room. So the fix is not a smarter agent. It is a seat in the room: a structure that delivers to the agent everything a trusted teammate would already know. The organizations getting real leverage from agents, the Ramps and Stripes of the world, converged on exactly this insight: agentic development is an infrastructure problem, not a tooling problem. That structure must do four things:

1. Carry intent to the agent. The prototype, the requirements, and the architectural reasoning must arrive with the task, not be re-derived from a two-sentence ticket. When product and engineering collaborate on one surface, the specification is the context, and there is nothing to drift.
2. Direct the work. Agents are versatile. For this reason, they are more difficult to use at enterprise scale. Complex tasks require complex solutions, and in a sea of possibility direction must be systematic. Golden paths, guardrails, and standing advisors on the hundreds of decisions that are made far before a ticket is ever created.
3. Verify the outcome, not the code. The review must shift from "does this diff look right" to "does this system behave correctly." Was any other dependency impacted? Will this handle the load of our existing users simultaneously navigating the page? Can this handle filtering across records if our database grows by 10x? Etc.
4. Capture the value. Every decision, constraint, and production signal must remain visible to both humans and agents, so the tenth table starts smarter than the first. The room's knowledge should accumulate, not evaporate.

Bolt-on tools cannot deliver this, because each one is another handoff. These properties only emerge when the environment is built as a whole.

V. Where We Fit

Karya ensures agents are always in the room. Product and engineering collaborate in one place, so the prototype, the requirements, and the reasoning live where the work happens, and intent flows to the agent instead of dying in a ticket. Every change is verified, approved by your engineers, and documented.

The tools of the AI era made us faster at every individual step and left the space between the steps untouched. That space is where the efficiency leaks out. Close it, and the smartest teammate you have finally gets to work the way the rest of the team always has: with full context, clear direction, and a verified definition of done. We believe every organization deserves that environment.