Everyone's automating code. That's the cheap part.

I’ll concede the obvious first: our engineers now ship code agent-first. Work that used to consume a sprint can land in an afternoon. If you run a small team in 2026 and have not moved in this direction yet, you probably will. I will not add to the growing pile of posts explaining why. Going agent-first in engineering was the easy win.

I want to talk about what broke afterward.

I’m the COO at Letterhead, a newsletter platform for publishers. In Q1, we decided the whole company would move toward agent-first work, beginning with engineering. Engineering got faster. Nothing else did.

Every feature we shipped became one more thing customer experience and sales had to learn, understand, and explain accurately. It was also one more product decision we had to make with limited information about how the previous feature had landed. Speed on the build side created immediate load everywhere downstream.

We had automated the increasingly cheap half of the work: producing code. The expensive half was context, and it was sitting exactly where it always had.

By context, I mean the current, structured knowledge required to make a good decision: how the product behaves, how customers use it, where they get stuck, what they expect the company to solve, which decisions have already been made, and which source of information should be trusted.

In a small company, that knowledge is real but scattered. Some of it lives in the code. Some is in an outdated document. Some is buried in an old feature request. Much of it sits in the head of whoever has been around the longest. Answering a difficult support question and making a sound product decision both depend on someone senior enough to know which source is accurate. That person does not scale, and agents that write code faster do not create institutional knowledge.

Our first attempts were not particularly organized. We let people build whatever they could imagine agentically. Some experiments became immediate wins. Plenty did not. Work drifted from the roadmap. Capabilities narrowly missed what customers were trying to accomplish. Some projects relied on stale information and sent us backward.

Agents move quickly, but when they are pointed at scattered or outdated context, they simply produce the wrong answer sooner. We realized that scaling agentic work required us to strengthen the foundation underneath it.

In Q2, we shifted our attention to the context layer. It was slower and far less exciting than putting a rocket under coding velocity, but it changed how the rest of the company could operate.

Our small revenue team built agents that update and personalize sales materials as quickly as the product changes. Our two-person product team rebuilt its workflow around setting direction, documenting decisions, and allowing engineers to make more decisions closer to the work. Product then shifted more of its time toward research, prototyping, and prioritization.

A feature enhancement for a priority customer that once took a week or longer can now often be completed in a day or two. The gain does not come only from faster coding. It comes from giving more people enough reliable context to make the right decisions with the agents they use.

Our CRM and support systems also could not keep pace with a two-person customer experience team, so we began simplifying them. Before migrating the data, however, we migrated the knowledge.

We mined old tickets, standard operating procedures, documentation, meeting notes, and sales conversations to rebuild our institutional memory in a form agents could read and help maintain. We then connected our systems of record so the team, and the agents they use, could answer from current product behavior and current customer information rather than from memory or outdated documents.

That changed the work of customer experience. Instead of acting as the company’s human search engine, the team could spend more time directly with customers: understanding use cases, identifying the harder problems worth solving, and helping customers adopt what we had already built. That has strengthened trust and brought customer needs closer to the center of our product decisions.

Next week, we are launching a new in-app chat for customers. It uses MCP skills to coordinate agentic features inside the product and is supported by an agent that answers from our growing context layer.

Each response carries a confidence score. High-confidence answers can go directly to the customer. Low-confidence responses route to a teammate for verification. The system then uses the verified answer to improve the underlying documentation, reducing the likelihood that the same information gap appears again.

The human is not a fallback added after the system fails. The human is part of the mechanism through which the system improves.

The two halves of the company are beginning to function as one machine. Faster engineering produces more features. More features produce more questions. The context layer absorbs those questions and turns them into current, usable knowledge. That knowledge, in turn, becomes one of the clearest sources of product signal we have.

The effects compound. Since the beginning of 2026, our team has become half its former size, while our release velocity has increased by more than tenfold. Bugs that once took days to resolve now close in hours and sometimes minutes. Customer-reported bugs have fallen substantially because multi-agent review applies a more consistent standard than a small team could maintain manually, while QA agents continuously test the application for regressions before changes are released broadly.

Code without context produces confident mistakes faster. Context without a fast build loop produces a well-documented company that ships very little.

A great deal of writing about AI-native companies stops at engineering. But when a company automates only code production, it creates work faster than the rest of the organization can absorb or use. Customers notice that gap before the org chart does.

A competitor can copy a visible AI feature from a demo. It is much harder to copy the accumulated context that makes the feature reliable: the product decisions, customer history, operating knowledge, and feedback loops that allow the system to improve. That is where the context layer starts to become more than an efficiency tool. It becomes a strategic asset.

We could not stop shipping while we rebuilt that foundation. Fortunately, AI had already made the build side inexpensive enough for us to continue releasing features while repairing the systems underneath them.

The work still required sustained senior attention. Fixing context consumed much of my own time last quarter, and every team lead carried part of the effort alongside day-to-day responsibilities. A small company cannot pretend senior attention is unlimited. We chose to spend it here because the company is also the laboratory. What survives contact with our own operations is what we trust enough to build for publishers managing operations of their own.

Automating code is becoming table stakes. Automating workflows comes next. The real advantage is whether your company’s context, and therefore its software, can keep pace with its customers.

Automate the coding, certainly. But build the context engine before the speed buries you.

‍

Rebekah Monson is co-founder and COO of Letterhead, software that helps you make, manage, and monetize communities starting with great email. She previously co-founded WhereBy.Us Media, whose local newsletter brands, Miami’s The New Tropic, Seattle’s The Evergrey, Portland’s Bridgeliner, Orlando’s Pulptown and Pittsburgh’s The Incline, engage more than a million curious locals each year. Rebekah also co-founded Commissioner, a local art membership program, and Code for Miami, the city’s first civic hacking organization. She serves on several professional and civic boards aimed at improving journalism, technology, and civic life, including LION Publishers and the Miami Foundation.