---
title: "Inside the Fable War Room"
speakers:
  - name: Ford Prior
    affiliation: GEICO
room: "Sutton Room (NY Ballroom W)"
starts_at: "2026-10-13T11:55:00-04:00"
ends_at: "2026-10-13T12:13:00-04:00"
format: "talk"
recording: "2026-10-13_1155_Fable-War-Room"
duration: "19m 13s"
source: "qwen3-asr-1.7b"
---

# Inside the Fable War Room

> Transcribed by qwen3-asr-1.7b with a schedule prompt. Possible prompt artifacts, names heard more often here than in the unprompted Voice Memos transcript (Qwen vs Voice Memos): Exa (1 vs 0), Ford Prior (1 vs 0). Check them against the audio before quoting.

### 00:00:00 — Breaking Out of the Outer Loop in Claims Engineering

Past years feels like all we've been talking about said, increase the velocity of our SDLC. Y'all know what I'm talking about — specifically, this big fat built chunk in the middle, okay, where we've been doing a lot of our coding in intellectual work, and sure enough, at least where I work, that step has basically been obliterated. Right? We reclaim a lot of time. But I think, and I'm no prophet in imagining some future where agents are doing the work, and humans are there in the middle as executive sitting on the stage.

But I work at Geico, and we're not a tech company. We're a risk management company, and risk management is baked into everything that we do, including the way we develop underwriter software. So while we've seen this interloop speed up to use Jean Kim's concept, we find ourselves seemingly stuck within the bounds of this outer, which is to say, everything that happens other than the current moment. And we find ourselves wondering what life might be like outside of these walls, in a world where the outer loop keeps pace with the inner loop. So this is a story of how we broke free, as it were, and my intention with this talk is to empower you guys to do the same.

Now, when Geico manages America's fleet of automobiles, or the risk therein, and something happens on the road, like an accident, we incur what we call loss, which is typically reported by one of our policyholders, and it becomes a claim. And claims technology is where the policy comes to life and gets the customer back on the road as quickly as possible with minimal disruption, which we call a resolution.

And I'm Ford Prior. I'm a senior staff engineer and tech evangelist embedded in a claims tech group at Geico. And I think I'm the only tech evangelist at Berkshire Hathaway. But basically, what that means is, within our three hundred engineer group, we have like thirty two pizza teams, as we used to call them, with a tech lead counterpart for each, business counterpart for each, and my job is to find and implement best practices in our SDLC.

I run a claims innovation lab, and I share stories like this one to attract the best engineers in the world to our problem space, which we find very interesting, not to mention an important part of the American economy. So a little bit more context and how we develop software: as many organizations do, we conceive of our work in terms of semantic versioning. And about six months ago, we looked at our backlogs and found that our engineers, after they finished their latest patch, or chase down the latest minor upgrade, had only 25 percent on a good day or less of their bandwidth to dedicate towards the major changes that keep us competitive, step ahead of the competition. That's like V one to V two to V three.

So we began strategically investing in Geico managed AI agents, on a variety of harnesses, using a variety of models, to offload that work all the way from spec to deployment for our patches and minor work, with the goal of redirecting or rerouting that work, so that our engineers can stay, our brilliant engineers can stay focused on the stuff that matters and that they find most joyful, which is to do the major work, which again, as I mentioned, is key to our competitive edge. Okay, so this is current state.

### 00:03:35 — Designing the Multiplayer AI-Native War Room

But as we look at this major work, we find ourselves rate limited by our ability to collaborate in rooms full of the right individuals summoned at the right time to make the right decisions at every interval in whatever life cycle would need to happen in order to get the major work done. And not only are we missing the ability to collaborate, but we're also missing this intelligence — is the ability to weave together all the variables relevant to the problem space as we learn it and deepen our understanding of it, including the fact checking, the code crunching, basically everything that needs to happen to serve up the insights as quickly as the decisions come up. And that's what ultimately gives us the confidence to bring those major changes to market. Okay, so it's collaboration and intelligence. We're missing both of those at the major change scale.

So to solve for this, we create a multiplayer AI native war room. And it consists of a roster of key decision makers and subject matter experts relevant to the topic, a driver to wield these expensive AI tools and an AI native productivity suite, which includes our comms channels for all the chatter, an interactive design studio — I can't mention the vendor names, take a wild guess — to for all of our collaborative elements, and then obviously we have our code repositories. And all of these are wired into a powerful combination of workflows, agent skills, MCPs, enterprise MCPs, and these agent fleets to do the heavy lifting, fact checking, synthesis, etc.

### 00:05:09 — Three Legacy Modernization Missions: Rentals, Damages, and Salvage

So my question was, how might we accelerate the delivery of agent callable APIs for legacy core capabilities? And for context, our legacy claims systems is like millions of lines of code. Okay, so and the deep context that we're trying to build here gets built once, and it can be reused. That's just some additional context, but my bet was that with a thousand dollars in hand of AI tokens, and one day, we could map out one domain end to end, including like graph representations of the business topology, all the complex code in our legacy systems and everything in between, and we can have the agents find and propose one serious change, which in our case we scoped down to an agent callable API in Tora Legacy claim systems, and have the whole thing deployed to our skills agent platform and running for a dinner to my boss at 4 p.m.

So I put the pressure on myself. But we ran this experiment three different times across three different code modernization missions. And this little taxonomy here, uplift, transform, reimagine, is from the entropic code monetization plugin, which I'll touch on in a minute. But the story is that first we looked at a rentals domain, which is a relatively simple one — that is all the tech behind you guys, your rental cars when your primary car gets in an accident. And we implemented a newer version of the same tech, which is in the definition of uplift, and we extended an existing API. And in this case, it was an interesting story because the agent used some interesting process to find and distill data to figure out that we can connect a couple dots and save ourselves eight and a half thousand calls per month by giving the customer up-to-date rental information.

So that was the first experiment that we ran, and then the second one was transformation of our damages domain, and damages is like, arguably, our most complex. No, sorry, damages. I'm not here. Damage domain is how we put dollar signs on a reported loss. And so, for this case, we built a set of new, ancient callable APIs to unlock a larger workflow, to be the damages data.

And then, lastly, we reimagined our salvage domain, which is arguably the most complex of the three. It's basically everything that happens when your car is totaled, and in this case, we produced a fully vetted migration plan with aspects and design. Okay, so it's like a fully vetted project plan that's ready to be implemented, which is like, as you guys know, is like that's like a milestone unto itself, getting everybody on the same page, including the template details, and honestly, like in this case, it understood the domains really well, and this and the story with the salvage work was that it found a prad bug. I can't talk about more, but it was.

### 00:08:10 — Vendor Stack, Enterprise Context, and FleetKit Orchestration

So, anyways, you may be curious about kind of what, like a little bit more detail on how this all worked. Really, like we had our friends at Anthropic who provide a bunch of stuff, and then we had Exa provided a lot of stuff. So on the left here we have the harness, the model, this thing called Fleet Kit, which I'll explain in just a moment, and this plugin that did code minimization tasks, that's on the left, brought by the vendor. Okay, you can replace any of that, by the way, with another vendor, another model, another framework, etc.

And on the right was the stuff that we can't place. This is everything that we need to punt. We had context in our knowledge base, including software standards and all of this past decision archaeology we had to do, list of tools that your agent can access on my machine and instructions for the agent on how to use it. We had the methods. Doing these out of order here. We had methods, which is essentially like all of our skills and all the kind of the quirky, domain-specific, highly optimized way that we develop software, probably different from the way you guys do it. And then lastly, judgment, which is like who can decide what and at what gate, right? So both from the subject matter expert point of view and from the decision maker leadership point of view, and we group them into two repos. But that allows us to have the agents add to it and correct it, and also humans do the same.

But that AI and this is kind of one of the interesting parts is expensive, right, to run at scale, and so we need to fleet manager, the Ph.D. Level fleet manager. And this was a bit of a collaboration with Anthropic, and it isn't open source yet, but I can share how it works today, in hopes that you guys can construct your own version because it's not rocket science. So Fleetkit is this tight structured collection of rules, protocols, instructions, all written in Markdown, optimized for the claw horn, specifically, table and designed around the core task of architecture transformation. And you guys can kind of guess, like this type of thing doesn't really work with some of the previous iterations of models, I think, like Opus 48 and beyond, I would I would guess is like something that can handle this type of like steering, because it's like one level above the actual system prompting, right? This is like rules that it has to follow, the agent has to follow.

And it's pretty simple. Takes a goal, breaks it down, dispatches leaders to do all the research and decide about the approach, puts everything into this like human loop cube. You could use GitHub issues, for example, something that the humans can comment on and approve, or that other agents can add more context. And then, when everything looks tight from a verbal standpoint, it dispatches the builders to do the rest. And in this case, we use needs. I'm not sure if you all know about — these kind of helps agents to track everything within their own piece of space. And ultimately, the goal is to produce what we call material change, which is like a change request into our systems or code change. And the ultimate like idea with this though is that like developing software looks less like playing in a canvas and more like working a factory.

### 00:11:18 — Interactive Worksheets and Architecture Diagrams in the Loop

Okay, I need to go faster. So ultimately, on the left here, you see these three repositories. They contain everything that's needed to run, including the fleet. By the way, all these slides are available in the blog post that I'll link at the very end. Can't tell these lights, but I just want y'all know that if you want to look at the visualizations that I'm showing here are on a blog post that was released today, and I linked it at the end. So all this boots up, gets pulled into a plug code session with a plugin. It's invoked, and you give it a mission to adopt or create a Slack channel, or in our comms platform, and then that's that mission channel is where everyone communicates. It's all the war remembers. The people are relevant, the decisions and the project are invited.

And every time the agent reaches a milestone, as it follows its nine-step process, it creates one of two artifacts. And by the way, on the right there, where it says War Room, that's where like it can ping individual people based on the roster. So, for example, it's missing some product details, it'll figure out who owns that from a property perspective. Did you mention that particular person? But other than that, it creates these worksheets that are like actually really well done HTML using Claude artifacts. People can fill them out. They're automatically saved, and that's to fill gaps, and also creates design documents, including like these like complex visualization of our architecture that didn't exist before, that teams were delighted to get because they kept them afterwards, that we can then edit, and an agent can then reread our edited like design documents, like Drawio or Figma, and then all that gets us — all that gets slurped back up into the session.

And if you have stumbled into our war room in recent beginnings, you know I'm from, this summary would have seen either a big code screen with a bunch of people huddled around it, or one of these two screens here. On the left is like a product worksheet that we had to fill out, and on the right, there is like one of our diagramming tools. And so, like the big gist with this, and the thing that was so delightful for me is that we were really high quality artifacts, so there wasn't like ever a question of like, why is the agent asking me dumb questions? It was like, wow, that's actually a great question that we've never thought about identifying an edge case either in the business with technology. And then the design artifacts, like I said, the teams can keep them afterwards, and oftentimes they were mapping stuff that just no one had taking the time, as y'all know, not every engineer loves doing diagrams.

### 00:13:46 — Cloud Code Dives, Local MCPs, and Nine-Step Execution

Okay, I'm skipping stuff here, but we're gonna keep it about like three minutes. These were in tools, just way simply. Basically, there's two types of agents: the code dives that we called them, where it did lots of code crunching and graphing of our of our legacy domain-specific languages that happened in the cloud, and then we had local agents running that have access to all of my laptop, my all the MCPS on my laptop, many of which were not in production yet, and enterprise specific, highly optimized for our problem space, and that can service really valuable data, including like chunked versions of the code bases that were being dived. So, there's a bindings file that I gave the agent to basically describe what's on my machine, how it works, and how to map it to FleetKit — or, you can see the built-ins. These servers.

The really quick, the code monetization plugin. This is at the heart of the whole thing, and what's inside of it, I think, you guys will find someone interesting, and I would encourage you to look into it after the fact, after this presentation, to get more information. I'm going to keep moving here.

Ultimately, the driver's laptop, my laptop, was the runtime. Okay, so I had to run nine steps that are that are started with the pruning step. So eight steps after that.

And what I want you to take from this super busy slide is that on the left here, those were all steps forked from the Code Mod plugin as we adapted it to our needs, as I would encourage you to do, and on the right, those orange colored elements or worksheets that were created, so that was going to require human approval, and so as we did this like modernization journey, you can see there's a lot of human input in the beginning, less on the on the end. Now the core of it was this code modernization plugin. And just an interesting detail, and this is something that the code monetization plugin does: is it does like a deterministic analysis of like, did the previous step create the artifacts that needed to include the file?

### 00:15:44 — Token Burn, Model Benchmarks, and Scaling Organization-Wide

So some interesting lessons. Obviously, I burned a lot of — I've learned a lot to Hookins and, just as a little takeaway, do not like Claude, Rank Fable, set of crumbs to check on work, because you'll watch a fable session each time and burn your budget annually. But some other interesting takeaways we had were relevant to property caching, which was way higher than I thought it would be, and then some pretty subagent behavior.

But one of the interesting things was, is like after we did the context building and have these agents dispatched to like write our complex legacy code, we ran benchmarks against like using our existing code recently written as the golden data and found out that Fable or Sonnet five wrote it just as good as, if not better than Fable. So, model selection for the wind. And then looking forward, I think you know, enhanced gate enforcement is going to be the biggest win that we have, in my mind, at least. We also have some interesting updates to make with decision models within our harness and within our model selection framework.

And then, are like — our context was just like markdown files, y'all. Like we didn't really have a complex way to graph things out. If we weren't using anything fancy with a like Graphify or Obsidian. I mean, any of these. I mean, honestly, if you guys find me afterwards, I love your input on this, but like a more optimized way to do search and look at all that contexts that we're using to inform this war room.

And then, lastly, audio is a data source. Like I want to turn over quarter on and have these conversations we have like automatically transcribed, but I had like instead, sit there and furiously write down all the notes that were happening during these meetings, and so that kind of like an extracting thing that I'm sure I've lost a bunch. So a less lossy way to incorporate inputs from the world. And then lastly, how can we deploy this thing across the organization?

Y'all find some group in your organization that doesn't know how to make decisions. Deploy this. Drive it. Control the cost. Make it yours. And at Geico, we're like trying to figure out how, as these agents are hill climbing and figuring out better ways to do things, where can we put humans in the loop? And right, how can we like put our best, brightest engineers who are receiving genius divine intervention, as it were, and have them pick the next hill as the agents climb the first one? All right, and that is it. We broke free of our Adalo loop. Now it's your turn, and that's the blog you guys can take a picture of — all right. Thanks for your time. Well, why are?