Inside the Fable War Room

Author: Ford Prior

Senior Staff Engineer, GEICO Claims Technology. Adapted from a talk at AI Engineer NYC on October 13, 2026.

For the past few years, much of the conversation in software has been about moving faster with AI. The traditional lifecycle has six stages, with a large build step in the middle. With AI, that build step has shrunk dramatically, at least in theory and for some teams in practice. A plausible next step is a lifecycle where agents do much of the work at every stage and people review and approve it.

Diagram comparing three software development lifecycles. Before agents, people did every stage: plan, design, build (the longest), test, deploy, maintain. Today, agents handle build only, which shortens that stage and leaves reclaimed time at the end. In the AI-native lifecycle, agents run every stage and a person signs off after each one, leaving the most reclaimed time.
Figure 01. Today, agents have sped up the build stage. In one possible future, a person signs off after each agent stage.

The outer loop is where we get stuck

GEICO is careful and methodical, and risk management is built into every step of how we deliver software. One might conceptualize an inner loop for creating the software and an outer loop which is everything it takes to get it to production. Our inner loop has become fast, but the outer loop is where our work still slows down. We set out to see what it would take to break out of it.

Nested loops: an inner loop of task, code, test inside an outer loop from system through operate.
Figure 02. Our inner loop is task, code and test, and our outer loop is system, context, owners, dependencies, intent, review, deploy and operate.

What Claims Technology does

Claims Technology exists to reduce friction from loss to resolution. When an accident happens, the systems we build help get people back on the road with as little disruption as possible.

Claims Technology is about 300 engineers in roughly 30 two-pizza teams, each with a tech lead and a business counterpart. Reliability and stability matter most to us, because they matter most to our policyholders. If you've ever been in an accident, you know how important this is!

Major work still needs collaboration and intelligence

One might sort engineering work at GEICO using semantic versioning; all work is either a quick patch, a minor upgrade, or a major evolution. Over the past six months, we've been exploring ways to shift more of the patch and minor work to agents, so engineers can spend more of their time on major iterations that help us transform the business and stay competitive.

As we've put more effort into major work, we've found that it still depends on two things. The first is collaboration, which means bringing people from across teams together to work through hard trade-offs. Intelligence is the second, which means having a capable AI model in every conversation to take notes, gather sources and keep track of the details behind each decision.

Diagram titled Collaboration. Five people connect by dotted lines to a single blue bar labeled Intelligence: deep context, one thread, start to finish. An arrow leads from the bar to a box reading Major work, 1.0 to 2.0.
Figure 03. Collaboration brings the people, information and decisions together. Intelligence keeps one thread across a long workflow.

A multiplayer, AI-native war room

Our answer was a multiplayer, AI-native war room. It has the same people as any project room, the decision makers and subject matter experts, plus a driver who operates the AI tools.

The room runs on tools our teams already use, such as our comms platform, our design tool and our code platform. Many of our teams are spread across the country, so the comms platform serves as the hub. Underneath, the room runs on workflows, skills, MCP servers and a fleet of agents.

Three people seated at a table, labeled Comms, Design, and Code, above a row of four building blocks: workflows, skills, MCPs, and agents.
Figure 04. Decision makers, the driver and subject matter experts sit at one table and work in our comms platform, design tool and code platform, with workflows, skills, MCP servers and agents underneath.

FleetKit gives the agents structure

FleetKit is the harness that organizes that work. It's a set of Markdown files and scripts that act as a detailed system prompt when a Claude Code session starts, and it's designed around subagents. It takes a goal, breaks the problem into threads and assigns a lead agent to each one. The leads delegate to teams of subagents, and their findings become a plan in issues on our code platform, which agents and people triage and approve. Builder agents then produce the changes, many of them as pull requests.

The driver sets a mission, leaders create issues, and builders turn them into drafts and pull requests..
Figure 05. The fleet is the agents. Agents and people approve plans as issues on our code platform, and the work lands as pull requests.

A one-day pilot

We tested the approach in a one-day, on-site session with engineering and executive leaders in the room. The goals were deliberately narrow. We wanted to:

  • build deep context for one domain
  • make one meaningful change in the form of an agent-callable API into our legacy claims systems
  • demonstrate that API, with an MCP server on top of it, in our user acceptance testing (UAT) environment by the end of the day.

The API was running in UAT for the end-of-day demo. Writes and the production rollout were out of scope by design, since the goal was to clear one barrier at a time.

Three kinds of modernization

We applied the same approach to three kinds of modernization, using the uplift, transform and reimagine categories from Anthropic's code-modernization plugin.

Rentals was an uplift. We extended an existing API to close a gap we saw in our telemetry, which could lower UX friction for customers who are extending their rentals.

Salvage was a transform. This was the one-day pilot described above, with new agent-callable APIs into the back end.

Damages was a reimagine. The result was a proposed new architecture, with a migration plan, specifications and mockups. It needed two additional days for review, because the new architecture required broad sign-off.

None of these was a finished, end-to-end delivery. In each case, the agents got the work to a point where our engineers could take over the final stretch.

Who brought what

While Anthropic brought the model, the harness, the FleetKit framework, and an open-source code-modernization plugin, these tools weren't enough on their own. GEICO had to supply four things:

  • context (our knowledge base, standards and past decisions)
  • access (what the agent is allowed to reach)
  • method (how we reason about architecture and change code)
  • judgment (who decides what, and on what authority).

Inside FleetKit

FleetKit draws its context from three places:

  • FleetKit itself
  • organizational context (GEICO)
  • domain context (Claims Technology)

When the driver runs FleetKit in Claude Code, all of it loads the same way each time, so every run starts from a consistent foundation. Given a goal, it opens a mission channel with the people in the room and uses worksheets and diagrams to gather their input.

A Claude Code session uses FleetKit context to open a mission channel, gather answers from people, and update a legacy application.
Figure 06. All it needs is a goal. It opens the mission channel and gathers answers through diagrams and worksheets.

Worksheets and diagrams

Two kinds of shared artifacts carry most of the conversation. A worksheet is an editable Claude artifact that the agent watches as people fill it in. Editable diagrams work in a similar way: the team edits them and then acknowledges the change on our comms platform, so FleetKit picks up the latest version.

Together, they help with much of the outer loop's friction, including system ownership, cross-team approvals, edge cases, and look and feel. Well-framed questions in these worksheets have started conversations that hadn't happened before. What we learn is saved to our claims context for future work.

Stages and gates

FleetKit works in stages, and the driver starts each one. The early stages each end with a worksheet that people complete and approve. The later stages rely on the review, testing and release gates we already have. Several stages are adapted from Anthropic's open-source code-modernization plugin.

The tools we relied on

Two kinds of agents did the work. Cloud agents handled deep dives into code, mapping and graphing large codebases, while local agents handled research and planning with the driver's own access. Plugins for our comms platform and design tool connected the room, and enterprise MCP servers gave the agents access to enterprise data in several formats, including code. The Claude Code built-in tools we used most fell into five groups: delegation, search, isolation, monitoring and publishing.

Measuring which model to use

We also asked Claude to build a benchmark from our own legacy code. It hides five APIs our engineers had already shipped, gives each model the same specification and scores each answer against our engineers' version with a plain script rather than an AI judge. On this test, Sonnet 5.5 scored about as well as Fable 5.1 at a much lower cost. The test has limits, since the grader checks the code statically and doesn't run it.

Chart: legacy API field recall stays between 82% and 87% for Sonnet 5.5, Opus 5.5, and Fable 5.1, from $0.06 to $2.80 per task.
Figure 07. On our legacy code, every model and effort except Sonnet 5.5 at max landed between 82% and 87%.

Agents still need human judgment

Agents improve every week at whatever we measure. Sometimes the result we need requires moving away from the current measure first and accepting a worse score for a while. An optimizer can't make that move on its own. It takes someone close to the work to notice that the team is optimizing for the wrong goal, which is why we see our engineers' judgment as the ceiling on what agents can do for us.

Two hills: climbing the one we measure improves weekly, but reaching the taller hill we need means getting worse for a while.
Figure 08. By divine, we mean someone close to the work.

Designing how people work with AI

Once other teams see an approach like this, they'll want to replicate it, so it helps to plan for that from the start. Understand the workflow and how to coach people through it, set clear boundaries and guardrails, and watch the effects, including cost.

What we're considering next

We're considering several next steps. For the engine, those include more sophisticated gate enforcement, harness and model updates, and better search and an ontology over our knowledge. In the room, we're considering ways to record meetings and decisions as they happen, so nobody has to transcribe them by hand. And on reach, we're considering where else at GEICO this approach could help.

The pilot cleared one barrier, and production is the next one. We're also hiring.