Building the ReAct Loop: Inside our AI Editor-in-Chief (EIC) Orchestrator

We had a working prototype. You could open a sidebar, ask it questions about your article, and it would respond. It knew about SEO. It could suggest headlines. It was, in the most literal sense, a chatbot with editorial knowledge bolted on.

It wasn't what we needed.

The problem showed up fast. A user would ask for feedback on their article structure, act on the suggestion, then ask a follow-up - and the AI would give advice that contradicted what it had just said. It had no memory of the reasoning behind its own recommendations. It was generating responses, not tracking work. Every message was, in effect, the first message.

That's the gap between a text generator and an editorial colleague. One produces output. The other thinks about what to do, acts, watches what happens, and adjusts. Building toward the second is what the ReAct agent loop is for.

The Setup: Why a Simple Chatbot Wasn't Enough

Editorial work is not a question-and-answer task. It's a continuous process with branching decisions, tool dependencies, and context that accumulates over time. When you're working on an article - iterating on structure, checking keyword data, adjusting the brief - the AI needs to hold all of that. Not just the last message. All of it.

The naive approach treats the AI as a text generator that responds to prompts. You send a prompt, it generates a response, done. This breaks down almost immediately in a real workflow. If the AI can't diagnose why a keyword API call failed, it can't recover from the failure. If it can't read where you are in the product, it can't prioritize the right tools. If it forgets the decisions made ten turns ago, it starts contradicting itself.

What we needed was not a smarter chatbot. We needed an agent that behaves like a colleague who knows the product, remembers what you're working on, and can recover when something goes wrong. The ReAct loop is the architecture that makes that possible.

The Orchestrator Manifest: How ReAct Powers the EIC

ReAct stands for Reasoning + Acting. The pattern is straightforward in principle: the agent thinks about what tool to use, calls the tool, observes the result, and decides what to do next. It's a loop, not a single pass.

Our Editor-in-Chief (EIC) orchestrator is built entirely on this model. It has a manifest of 20+ specialized tools - SEO analysis, structure auditing, keyword fetch, domain verification, and others. At any given moment, it is not generating an answer from memory. It is reasoning about which tool to call, calling it, and responding based on what comes back.

Two mechanisms make this work in practice.

The first is context-aware routing. The EIC reads the current page and editor state before it selects tools. If you're inside the Article Editor, its tool priority shifts toward SEO analysis and structure auditing. If you're elsewhere in the product, a different subset of tools becomes primary. This isn't a configuration setting the user controls - it's the agent reading state and adjusting. The practical effect: the EIC gives relevant responses because it knows where you are, not just what you asked.

The second is the loop itself. The EIC doesn't generate a response and stop. It acts, observes the result, and iterates. If a tool call returns unexpected data, the loop doesn't terminate - it re-evaluates. This is what separates a reasoning agent from a text generator.

This is not a feature layer on top of a chatbot. It's the operating model. The EIC is an agent that reasons about what to do, acts, and learns from the result of each action. The conversational interface is just the surface.

The ReAct Loop in Action: Diagnosis and Recovery

Here's where the difference between a chatbot and an agent becomes concrete.

A user asks the EIC to fetch keyword data. The API returns a 404. A chatbot would surface a generic error message - something like "Error: API call failed" - and stop. The user is left to figure out why.

The EIC does something different. It doesn't treat the 404 as a terminal state. It re-enters the reasoning loop. It checks the tool's preconditions: is the domain verified? In this case, it isn't. The EIC identifies that as the root cause, then surfaces a specific fix - the onboarding step the user needs to complete before keyword data will be available.

That sequence - fetch, fail, diagnose, recover - is the ReAct loop doing what it's designed to do. The tool manifest includes preconditions for each tool. When a call fails, the EIC has enough information to check those preconditions, identify what's missing, and suggest a path forward rather than a dead end.

The shift this represents is from generative AI to agentic AI. Generative: produce text. Agentic: think, act, observe, iterate. The 404 example is small, but the pattern scales. Any failure point in the workflow becomes a diagnostic opportunity rather than a hard stop. That shift is also why editorial judgment remains essential even as agents take on more of the execution work - a loop that can recover from failure still needs human oversight to catch the failures it doesn't know to look for.

What Went Wrong: The Token Bleed and the Compaction Fix

We did not anticipate how much context a real editorial workflow would consume.

We built the EIC for short, transactional interactions. Ask a question, get an answer, move on. Real users don't work that way. They open the editor, iterate on an article for 45 minutes, ask for feedback after each change, and build up a long conversation history in the process. Long-running sessions like that push conversation history toward token limits - and when you hit the ceiling, something has to give.

Our first instinct was simple truncation: drop the oldest messages. It was a reasonable starting point. It didn't work. When we cut the early context, the EIC lost the reasoning behind earlier structural decisions. It would contradict advice it had given 20 turns back. Users noticed immediately. The agent had stopped being coherent.

The real fix was a Conversation Compaction Strategy. After every N turns - or when the token count hits a defined threshold - the EIC summarizes the conversation history. But the summary is not a generic recap. It preserves two specific things: editorial intent (what the user is trying to accomplish with this article) and critical decisions (the structural and strategic choices already made). Everything else - the back-and-forth, the intermediate reasoning, the exploratory tangents - gets compressed.

This keeps the agent coherent across long sessions without blowing the context window. The EIC doesn't forget why certain decisions were made. It forgets the noise, not the signal.

The honest version of this story: we should have designed for long-running sessions from the start. The editorial workflow is not a series of isolated queries. It's a continuous process, and the agent needs to hold that continuity across the full session. Compaction is the mechanism, but the lesson is about what we failed to model when we built the first version. Those compaction decisions are also exactly the kind of place where human review inside AI content workflows catches what automated summarization misses.

Why This Matters: Agentic AI vs. Generative AI

A chatbot generates text. A colleague thinks, acts, observes, and recovers. The ReAct loop is the architecture that closes that gap - but only if the rest of the system is built to support it.

Generative models are table stakes now. Every AI product can generate text. The difference is in what happens when the text generation isn't enough - when a tool fails, when context accumulates, when the workflow requires decision-making across multiple steps. That's where reasoning and action matter, and where most AI-assisted tools still fall short. The broader organizational shift this points toward - moving from human-executed workflows to agent-executed ones - is something the data on agentic marketing transformation is only beginning to quantify.

The EIC doesn't compete on text quality. It competes on coherence across a session, on recovery from failure, on knowing where you are in the product and prioritizing accordingly. Those are operational properties. They come from the loop, the tool manifest, the compaction strategy, and the precondition checking - not from