As a Head of Community, I spend enough time talking to founders building in AI. The same question keeps surfacing in different forms: what actually breaks when the prototype hits real data, real users, real systems, and a team that has to support all of it?

That question ran through several of our June Gradient Descending sessions across London and Munich, even when the topics seemed quite different from each other. We covered agent harnesses with Steffen Haussman from LangChain, forward deployed engineering with Anjor Kanekar, and building AI-native engineering teams with Dan Mankowitz from Ethos AI, who just closed their Series A led by a16z. 

The control layer is the product

The LangChain session made something clear that I think a lot of builders still underestimate: once agents start running for longer, touching more tools, and handling tasks beyond a single request, a completely different class of problems appears. Context blows up. Summaries start dropping details. Tool outputs get too large. Hallucinations become harder to spot. Costs start to matter in ways they didn't during the demo. Human approval becomes necessary before an agent takes a destructive action, and you need some way of understanding what actually happened after two hours of autonomous execution.

At that point, what you're really building is not the model, it's the control layer around it. Context management, checkpointing, planning, sub-agents, approval flows, tracing. All of that becomes core product and engineering work. One story from the room stuck with me: an engineer accidentally spent $35k overnight on a runaway agent. It sounds almost comic until you realise how quickly a clever prototype becomes an operational system with real cost and real failure modes attached to it.

The first custom thing is rarely the product

The session with Anjor took a different angle but landed in a similar place. What I found most useful was how grounded it was, not abstract org design, but what actually happens when a customer needs something your product doesn't quite do yet.

The first version is often awkward, held together with scripts, missing pieces, and workarounds. But that awkwardness is frequently where you learn where the product should go. Anjor walked through an example where a custom workflow built for a large manufacturer started as a Python script that removed a painful set of manual clicks. A few months later, the part that turned out to matter wasn't the script at all, it was a general metadata service that grew out of it. That felt like a very familiar AI pattern: the first bespoke thing is rarely the product, it's the thing that teaches you what the product should become.

That tension is everywhere right now. Founders are constantly deciding what to keep custom, what to generalise, and when they're still proving value versus when they're ready to build a proper abstraction. Generalise too early and you build machinery nobody needs. Stay custom for too long and you never get leverage. Forward deployed engineering, in that sense, isn't just a services model, it's a way of discovering what the product actually is.

The job is starting to feel more like managing than coding

Dan Mankowitz described the strongest engineers on his team as generalists: people who can move between product, UI, infrastructure, customer issues, and code without getting stuck in one lane. He talked about running several features in parallel, building stronger internal context through agent files, and using AI not as a one-off tool but as part of the normal workflow. His observation was that the job is starting to feel more like managing than coding and not because coding matters less, but because more of the leverage now comes from directing multiple systems and workflows at once.

The team uses different tools for different kinds of work: Cursor for exploratory and visual tasks, Conductor for parallel work across multiple branches. Agent files serve as internal memory, particularly for things like database schema context. They use AI for debugging real production issues, not just writing greenfield code. Even the path to production has changed with simplified workflows, more responsibility pushed into automated checks, migrations, and review. The teams that look AI-native aren't just faster because of tools, they're structured differently.

The conversation has moved one layer down

What keeps coming up in founder conversations now is a different kind of question entirely: How much autonomy should the agent actually have? What belongs in the harness and what belongs in the product? When does a customer request point to a product opportunity rather than another bespoke workaround? What kind of engineers do you need if a big part of the job is now orchestrating systems rather than building everything by hand?

A lot of the public conversation around AI still sits at the surface: models, benchmarks, demos, interfaces. The more useful founder conversations are happening one layer below that, in the messier parts of the stack: the product boundary, the context layer, the deployment model, the team design, the infrastructure around the model. That's where Gradient Descending tries to live, and it's where I think the most honest thinking is happening right now.

— Anna Andersson, Head of Community & Events at Earlybird