Success is Where Most Agentic Projects Quietly Fall Apart

By DAVID KRAMER

The MVP shipped. The team started using it immediately. It answered questions that used to take 20 minutes of cross-referencing Gong, Salesforce and Slack.

Every time someone got a fast, grounded answer about an account, word spread. People stopped asking, “Should we trust this?” and started asking, “Why can’t it do this yet?”

That’s the moment the pressure changes. When something works, people don’t stop using it — they start expecting more from it. They want it to remember last week. They want it to know what changed since the last call. A stateless system under that kind of pressure isn’t a prototype anymore. It’s a liability.

This is what the construction phase of AI-DLC feels like from the GTM side: not a scheduled architectural upgrade, but a growing list of things the system can’t do that the team now counts on it to do.

I handed it to Allen. Not because he wrote every line, but because he knows how to direct agents that do. The mindset matters more than the stack. Allen operates as a conductor: agents executing at speed, humans directing with intent and reviewing output critically, the loop moving fast because the oversight is built in, not bolted on.

Three problems, fast. Within weeks of the team actively using it, three problems became visible.

The first was memory. The system handled simple, single-turn questions well. But anything that required continuity, such as, “What did we talk about last week with this account?” or “What’s changed since my last call?”, it had nothing. Every conversation started from scratch. Smart, but amnesiac.

The second came at scale. Multi-turn conversations started hitting Claude’s 200,000-token context limit. We built a compaction system; when a thread ran too long, the agent summarized the conversation history and continued from the summary. Users never saw an error. But it was a workaround for a stateless architecture, not a fix.

The third was the one that mattered most. An AI agent is only as good as the data integrity of your underlying systems. We had gaps — sources that weren’t being indexed, records that weren’t making it into the knowledge base. When the system gives a confident answer that turns out to be incomplete, trust erodes faster than it was built.

 

The decision. The honest conversation happened a few months ago. Three features on the roadmap were stacking up: a product feedback pipeline that routes field signal to Linear, a bi-weekly newsletter that synthesizes account activity across the book and a license automation workflow tied to Salesforce opportunity stages. All three had something in common. They are fundamentally stateful. They require knowing what happened before — across conversations, across team members, across time.

LangGraph was the answer. Real state persistence. A structured runtime with inspectable nodes. Visibility into exactly where the model was going and what it was writing. Once we put the problem on the table, the decision was easy.

What LangGraph changed. LangGraph replaced the stateless request-response loop with a structured three-node graph: load context, reason and respond, then write what was learned back to a persistent state file. After every conversation turn, the agent writes a snapshot of what it knows about the account — commercial context, relationship history, open signals — that survives across sessions and across users.

That file is the foundation everything downstream reads from. The newsletter delta engine reads it to know what changed in the last two weeks. The product feedback pipeline reads it to weight field signal by revenue. The license workflow reads it to detect opportunity stage transitions and trigger approvals. We’ve written six PRDs since the migration. Every one of them depends on knowing where an account is, what’s changed, and what the model did last time. None of them required additional wiring to inherit that context.

The hardest stretch during the migration was account identity contamination. When a conversation touched multiple customers, the agent was writing one account’s data into a different account’s journey file. Tracking it down required isolating exactly where the state write was resolving customer identity, and adding an explicit filter to pin each write to the correct account ID. It’s the kind of bug that only surfaces when real users start asking real questions. And it’s exactly the kind of thing a structured graph makes easier to inspect and fix.

Governance enters the architecture. The migration forced a governance conversation we’d been deferring. In a stateless system, governance lives in the prompt; the model is instructed what to do and trusted to follow it. That’s not enough when persistent state is feeding six downstream workflows. Governance has to be structural. Access has to be enforced at the architecture layer, not expressed as instructions the model is expected to honor.

But the more important shift wasn’t technical. It was cultural.

At some point during construction, the team stopped thinking of Project Animus as a tool and started thinking of it more like a co-worker — one with a specific job, a defined scope and clear boundaries around what it’s authorized to do. That sounds like a small reframe. It isn’t. Because when you think about an agent that way, you start asking completely different questions: What is it allowed to see? Who approved this task? What did it actually do, and can we trace it?

You wouldn’t hire someone and hand him or her the keys to everything on day one. You’d build trust incrementally — have them shadow, review his work, expand access as he earns it. We applied the same logic to Animus. Human-in-the-loop checkpoints aren’t a safety hedge. They’re just good management.

The cultural decision underneath all of this is: AI activity is organizational activity. It’s not individual behavior, and it’s not a black box you audit after the fact. Governance that lives above the work or after the work doesn’t work. It has to live where the work happens — in the architecture, not in a policy document.

That shift — from implicit to explicit, from policy to structure — is what construction is actually about. Not just building the thing. Building it in a way you can inspect, audit and hand to the next person.

Governance forced a new problem: the interface. Here’s something we didn’t fully anticipate. Once governance became structural — once we were enforcing access tiers at the tool layer, routing different data to different roles — we ran into a limit we hadn’t planned for.

Slack.

Slack is a chat interface. It’s excellent at async communication. It’s how Project Animus was born, and the Slack bot remains the primary async channel for quick questions. But a chat interface treats everyone the same. It can’t give an SE a visual of where their deals are. It can’t show a CSM which accounts are drifting on health. It can’t let a product manager see field signal themes without exposing deal-level data they shouldn’t see. It has no concept of workspace — of persistent context around an account that survives across sessions, across teammates, across time.

When governance is structural, the interface has to be, too.

So we built one. Project Animus now has a web UI in development — a dedicated workspace that serves the whole company, not just customer solutions. The architecture is the same intelligence layer underneath but surfaced correctly for each role: pre-sales Kanban for SEs working POCs, health dashboards for CSMs managing the book, aggregated trend views for product and marketing, a full cross-functional view for leadership. The ask bar is present everywhere — always scoped to the context you’re working in, always enforcing the access tier you’ve been assigned.

It’s not a CRM. Salesforce stays the system of record. It’s a workspace and intelligence layer on top of the systems that already exist — visual, role-aware and structured in a way Slack never can be.

The insight that drove this: governance isn’t just about what the model can and can’t return. It’s about designing the right interface for every person who needs intelligence from the system. When you get governance right architecturally, the interface question almost answers itself.

What the process proved. The phase moved faster than expected because the upstream work was done right. AI-DLC compresses the build loop when Inception is done properly. We didn’t relitigate architecture decisions mid-sprint because those decisions were already made, documented and agreed to before a line of code was written. The sprint became execution, not negotiation.

That’s not how software usually gets built. Most teams are still debating the architecture while they’re building it. The back-and-forth is expensive — not just in time, but in momentum. AI-DLC front-loads that friction intentionally. By the time construction starts, the team knows what it’s building and why.

The six PRDs we’ve written since prove the point. We didn’t have to rebuild the foundation to add the newsletter, the feedback pipeline or the license workflow. We just read the state file. That’s what you’re actually buying when you get the architecture right the first time.

What it’s doing to the team. The industry landed on forward deployed engineers for a reason. Put deeply technical people directly in the field, embedded with customers, closing the gap between what a product can do and what a customer actually needs. It works. It’s also expensive to scale — the institutional memory lives in the person, and every engagement requires the same effort.

AI changes the underlying constraint.

When the system carries the context — account history, relationship signals, what changed since the last call — the team stops reconstructing and starts advising. The work moves earlier in the relationship, where it has more leverage. The 20 minutes of prep converts to sharper questions and faster time to what the customer actually needs.

The institutional memory stops being a person. It becomes infrastructure.

That’s the concept we’re building toward — what we’re calling “Field Delivery Engineering.” Same acronym as the industry model, different architecture. Not a title, not a reorg. A model where technical depth, relationship continuity and AI-held context operate as one thing. Built around what Coder sells, how our team works and what our customers actually need from us in the AI era.

The real work was always judgment, credibility, relationships. Project Animus is building the infrastructure to make more of it possible.

David Kramer is VP of customer solutions at Coder.