Your AI Pilot Isn't Stuck in Procurement. It's Stuck in Open-Loop.

Every Monday at Tendium, Hugo spent five hours manually joining data from three sources: a CRM export, a pipeline spreadsheet, and a market-mapping CSV. Cross-referencing, deduplicating, formatting. Five hours, every week, to answer one question: who do we contact next?

We shipped one agent. The same Monday join now takes 30 seconds.

Here's what I want you to notice: the models were identical before and after. Claude was available to Hugo before we built it. The improvement had nothing to do with which model we used or what it could do in a chat window. What changed was the plumbing. We connected the agent to live data. We made the output write back into a system the rest of the workflow could read. We closed the loop.

That's the distinction most AI pilots miss entirely. And it's why they don't scale.

Open-Loop vs. Closed-Loop

Diana Hu, a General Partner at YC, draws the sharpest line I've seen between companies that use AI and companies that compound from it. She calls them open-loop and closed-loop companies.

Open-loop companies are the default. Decisions get made, actions get taken, and then nothing. No structured output. No feedback. No machine-readable record that the next step can build on. Information leaks constantly because the system was never designed to retain it.

Closed-loop companies instrument every important workflow. Every output produces a structured artifact. Every action feeds back into an intelligent layer that uses it to improve the next cycle. The system compounds because it can read its own history.

Most scaling companies are open-loop. Not because their people are unsophisticated. Because their processes predate AI, and nobody has gone through the unglamorous work of wiring them up.

Why Pilots Fail to Scale

The typical AI pilot follows a predictable path. An enthusiastic team identifies a promising use case, exports some data, builds something that works in a demo, and then... stalls.

The stated reasons vary. Procurement. Legal review. Model limitations. Change management. These are real, but they're rarely the actual blocker.

The actual blocker is this: you cannot automate what you cannot observe. The pilot was built against a static export, not a live feed. It has no way to know what changed since the CSV was pulled. It can't write its outcomes back anywhere the next step can read. It was built as a standalone tool in an open-loop company, and it stays exactly that.

The model worked fine. The agent was capable. What failed was the infrastructure around it. There were no machine-readable artifacts. There was no queryable state. There was no trigger that closed the loop.

"Every important process in your company should be captured by an intelligent closed loop." — Diana Hu, General Partner, Y Combinator

Until your company is closed-loop, every agent you build is a one-off. It runs once, produces output that gets manually handled, and the cycle resets. That's not automation. That's assisted manual work with extra steps.

What Closing the Loop Actually Requires

This is the work most pilots skip. There are three non-optional components.

None of this is complicated in concept. All of it is skipped in practice. The reason: it requires someone who can hold the data model, the agent behavior, and the production system in their head simultaneously, and who is actually on-site with the team to understand which workflow to instrument first.

The knowledge problem compounds when you add multiple agents. @pejmanjohn described this as giving every agent its own skull: each agent re-derives context from scratch, unaware of what the agent next door figured out an hour ago. The isolated agent is a design choice, not a necessity. A shared context layer (which is what MCP enables) collapses that problem.

A Concrete Example: The Tendium Monday Join

Here's what open-loop and closed-loop looked like in practice at Tendium.

The model did not get smarter. What changed: the agent now had live data to act on, and its output was structured enough for the next step to use. One loop, closed. That's it.

The First Build Is Not a Prototype

When founders hear "two-week AI build," they expect a demo. A proof of concept. Something to show the board.

That framing is exactly what produces open-loop pilots that don't scale.

The First Build at nativefirst is something different: one workflow instrumented end-to-end, acting on live data, writing structured output back to a queryable state layer. Not a demo. The first loop, closed. In production. In two weeks.

It's not the most impressive thing you can build. It's not designed to be. It's designed to be the first brick in a closed-loop company. The second loop is faster to close than the first. The third, faster still. That's how Tendium moved from one agent to a full Customer Graph in a matter of months, not years.

The Install continues that work monthly, function by function, until the company runs on closed loops. Not because the models improved. Because the infrastructure did.

Where Is Your Open Loop?

You probably already know which workflow it is. There's a process somewhere in your company that produces output nobody else can use without first touching it manually. A report that lives in someone's inbox. A data join that happens in a spreadsheet. A qualification step that depends on one person's head.

That's the loop to close first. Not the most ambitious agent you can imagine. The one workflow that, if it produced machine-readable output and wrote to a queryable state layer, would immediately unlock the next two automations downstream.

Find that workflow. Close that loop. The rest compounds from there.