← Back to Thinking
Eating our own Dogfood

The first agent went live in under a month. Here's what happened.

Tim Jordan · March 16, 2026 · 5 min read

The first real test of any platform isn’t the architecture document or the database schema or the pipeline diagram. It’s the moment something built on the platform has to do actual work for a real business. For us, that moment came faster than I expected.

We had the cognitive pipeline running, the model routing was handling requests, the memory system was persisting information across conversations. On paper, the system was ready, so we birthed an agent and pointed it at one of our ventures.

What “birthing” actually means

I should explain what we mean by that, because it’s not what most people picture when they think about deploying an AI agent. We don’t spin up an instance and feed it a prompt. Birthing an agent means creating a persistent organizational entity with a defined role, a set of capabilities, memory that accumulates over time, and governance that constrains what it can do.

The agent gets a backstory. It gets assigned to specific cognitive slots that determine which models handle which parts of its reasoning. It gets tool permissions. It gets dropped into the organizational context of the venture it’s serving.

This takes thought. Not months of thought, but you can’t just flip a switch.

What worked immediately

The cognitive pipeline held up, messages came in, the agent prepared its context, reasoned through responses, verified its work, executed tools when needed, and delivered outputs. The 5-stage loop ran without intervention.

Memory worked, the agent started accumulating information about the venture, its operations, the decisions being made. Day two was noticeably better than day one because the agent remembered day one.

Model routing distributed the cognitive load across different models without any manual intervention, the reasoning model handled complex questions, the fast model handled classification and triage, the local models handled embedding and extraction. All of this just worked because we’d built the routing table before we birthed the agent.

What broke

The first thing that surprised us was the gap between “the agent can do this” and “the agent knows it can do this.” We had 46 tools registered in the system. The agent had access to a subset of them. But the agent’s awareness of its own capabilities was inconsistent. Sometimes it would try to do something manually that it had a tool for. Other times it would reference a tool that wasn’t available in its current configuration.

This is a tool visibility problem, and it’s harder than it sounds. The agent needs to know what it can do, what it can’t do, and how to discover capabilities it doesn’t know about yet. We ended up building a dedicated tool discovery module that uses semantic search to surface relevant tools based on the current task.

The second surprise was memory management, and this one was trickier. The agent remembered things, which was the point, but it remembered too much—or rather, it recalled too much at once. When the context window filled with every marginally relevant memory, the reasoning quality dropped, the agent was drowning in its own history.

That’s when we built the token budget ceiling at 80% and the gradient compression system, and it turns out constraints were the answer, not more capacity.

What we learned about assumptions

I went into the first deployment assuming the hard part would be the reasoning, making the agent “smart enough.” It wasn’t. The language models we were routing through were plenty smart for the tasks at hand.

The hard parts were all operational, context management, tool awareness, memory relevance, the gap between what a component does in isolation and how it behaves when it’s part of a running system. These are the same kinds of problems you hit when onboarding a new employee, the person is competent, but the organization around them needs to support that competence.

That parallel kept coming back, and it kept resonating. The agent didn’t need to be smarter, it needed better organizational infrastructure around it, which was basically the thesis of the whole project. But it’s one thing to believe that theoretically and another thing entirely to watch it play out in real time.

The compound effect

The thing nobody warned me about was the compound effect, and it was striking. By day three, the agent had enough accumulated context that its responses started feeling qualitatively different, not “better AI” different but “understands the situation” different.

It knew what we’d tried before. It remembered which approaches worked and which didn’t. It could reference past conversations when making recommendations. That continuity changed the entire dynamic of working with it.

I keep thinking about what this will look like at six months. At a year. If three days of memory accumulation produced that much improvement, what happens when the agent has genuinely deep institutional knowledge?

I don’t have the answer yet. But the trajectory is clear enough that I’m not worried about whether this works. I’m worried about whether we’re building the governance to handle it well when it does.

← Back to Thinking