Agent-Centered Design in Practice: How We Rebuilt Agentic Document Extraction for the Agent as a First-Class Citizen

For most of my career, the person reading our API docs was a person. Somewhere in the last stretch, I watched that stop being true. More and more, the thing calling our endpoints was an AI agent that a developer had deployed, discovering the API, reading the schema, and acting on the output with no human in the loop.

So when my team set out to rebuild Agentic Document Extraction (2nd Generation), I made that shift the premise of the whole project. The primary user of ADE Gen2 would not only be the developer. It would be the agent the developer employs. This is the story of what that decision changed for us, and what I would tell other engineering leaders who are about to make the same call.

A companion post lays out the discipline in the abstract. Here I want to walk through what it looked like in practice for my team.

The audience for software is changing

When I ask who our software actually serves now, I have to include software in the answer. Early in this project, I found myself telling the team that our target was shifting from the developer toward the agents that developers would employ. Saying it out loud made it real.

That is not a cosmetic change, and I did not treat it as one. When the consumer of an API is an agent, the constraints move. Documentation has to be machine-readable, not just skimmable by a human on a coffee break. Interfaces have to be discoverable without a person to interpret them. Outputs have to be structured and verifiable so that an agent can act on them and prove its work. A lot of what we used to file under nice-to-have became load-bearing overnight.

What agent-centered design means

We kept coming back to one definition, and it is one I think our industry should adopt:

Agent-centered design is a technique that puts AI agents at the center of the development process, delivering products built by and built for agents as the primary end user of the product or service.

The contrast with human-centered design is what made it click for me. Human-centered design put its energy into user experience and how the end customer felt using a product. Agent-centered design treats the agent itself as the end user. The agent is who reads our docs, who calls our API, who consumes our output.

I see a sibling idea gaining traction in the industry: harness engineering, the practice of building the guardrails, tools, and feedback loops that let agents operate autonomously and reliably. Both ideas point the same direction, and both changed how I think about my own org. The boundary between the engineers who build a product and the developers who consume it starts to melt away, because both sides end up using the same frameworks and the same practices to work with agents.

Built by agents

The first half of that definition is "built by agents," and this is where my day-to-day changed the most. We leaned on AI coding agents heavily across the whole software-development lifecycle: writing code, deploying it, running QA, and handling post-deployment DevOps.

Once writing code got that cheap, I had to accept that the unit of engineering work had changed. The human pull-request-and-review loop, where one of our engineers reads every line of a change, stopped being the right unit of work. When an agent can produce a service quickly, the leverage is no longer in reading the diff. It is in the boundaries you draw around what the agent produces.

So I pushed the team toward strong interfaces and strong tests. We define a clear contract for a service, wrap it in unit and integration tests, and let those boundaries hold the agent's work accountable instead of reading the implementation line by line. In effect, the tests became the review.

That was a real adjustment for experienced engineers, myself included. But it is the change I would most want to prepare another engineering leader for, because it reshapes what leverage even means on your team.

Built for agents

The second half is "built for agents." ADE Gen2 is API-first, and we designed it so that an AI agent is the primary consumer. That premise showed up in three concrete choices my team made.

Agent-as-integration-test

One of our qualifying criteria for release became a question I would ask directly: given a simple prompt, can an agent build something complex on top of these APIs? If an agent could not discover and compose the product on its own, we did not consider it ready. The agent's ability to succeed became our test.

A layered surface for agents

An agent needs more than one way in, so we built a layered surface. We ship direct APIs, SDKs in Python and TypeScript, CLIs, agent-friendly documentation including machine-readable llms.txt-style docs, and plugins and skills such as a coding-agent plugin. Every layer exists so that an agent can discover the product and use it in whatever form fits its context.

Self-describing APIs

We leaned on a pattern of lightweight clients that fetch the current OpenAPI or Swagger spec on demand. The agent loads only the context it needs, when it needs it, rather than carrying a stale copy of the whole surface. Clean, self-explanatory APIs and well-formed JSON schemas mattered to us before. Once the consumer was an agent, they mattered more.

The through-line: context management

If I had to name the single idea that held the whole rebuild together, it is that agents exist to manage context. I watched large language models degrade when we overloaded them, and the drop-off started well before the context window was technically full. The point of an agentic architecture, in my view, is to give each agent just enough context to do its job well.

That principle is visible in what we shipped.

Extract decomposes a large or complex document into self-contained sub-problems and dispatches them to agents that each work with limited context, in parallel. We stopped dumping hundreds of pages into a single model call and hoping the model would find the needle in the haystack. Smaller, bounded problems gave us more reliable answers.

Grounding runs natively and at fine granularity, down to the word level, so every extraction traces back to its source in the document. I think of that as our trust layer. An agent acting on an extraction can point to exactly where the value came from.

Proof: what ADE Gen2 delivers

Principles are worth little without a shipped product behind them, so let me show you what agent-centered design let my team deliver.

ADE Gen2 rests on two core building blocks. Parse converts any document, whether a PDF, a scan, an Excel file, or a Word file, into LLM-readable markdown that preserves the semantic content and the grounding information. Extract turns that markdown into computable, schema-defined structured JSON that an agent or an application can act on directly.

The parsing is content-aware and structure-aware. It reads a document hierarchically, from the chunk level down to the word level, and it understands tables semantically, telling a real table apart from a layout that merely looks grid-like. Grounding is fine-grained to the word level, so outputs stay auditable and traceable.

We made pricing complexity-based, so the cost reflects the difficulty of the document rather than a flat rate.

Parsing runs on two models, DPT-3 Pro and DPT-3 Fast, where DPT stands for Document Pre-trained Transformer. Alongside Parse and Extract, ADE Gen2 includes Split, Classify, and Section services, plus attestation detection. It exposes MCP-based tool design, plugins, and skills for agent consumption.

And the building blocks are composable. We kept them foundational and independent enough to be recombined, so our partners can build verticalized solutions on top of them.

The boundary between building and consuming dissolves

Here is what closes the loop for me. The same agent-centered approach we used to build ADE Gen2 is the approach our developers and their agents use to build on ADE Gen2. Same development practices. Same frameworks. The line between the team building the product and the teams consuming it keeps thinning, and I no longer expect it to snap back.

We sit at the base of the pyramid, offering research-heavy building blocks. Others compose more on top. As the primary consumer of software shifts from the developer to the agent, that shared foundation is where I believe the leverage will live.

If you are building document processing or agent solutions, here is my invitation, leader to leader: treat the agent as your user, and see what it can build on building blocks designed for it.

Try the finished product

If you (or your agents) would like to try the document intelligence building blocks discussed above you can get started at ade.landing.ai

We recommend that you point your agents at Build with AI Agents for them to gain the full context of what’s available to them and how to to use each component.

Happy building.

Daniel
VP of Engineering, LandingAI