AI Agents Are Now in the 'Run' Phase. 3 Conditions to Move Past PoC

You’ve tried ChatGPT. You’ve tried Claude Code. Some of you have built a proof-of-concept agent. The next question is this: “Is that agent still running?”

Among the people I know, the number of agents that got abandoned at PoC has grown sharply. The reason isn’t one thing — it’s not the prompt and it’s not the model. The operations design was absent from day one. That’s the core issue.

IBM framed 2026 as the year enterprises stop “building” AI agents and start “running” them. There’s barely any English-language analysis of this framing that cuts through the noise. But it’s the most useful lens available right now for anyone who stalled at PoC.

Using IBM’s “year of running” framing as a starting point, I’ll lay out the 3 conditions for getting an AI agent into sustained operation. This piece is structured so you can walk away with the one design flaw to fix this week and 3 actions you can start within 7 days.

A note on sourcing in this article Following a recent editorial note (2026-05-25), this article explicitly distinguishes between “officially confirmed facts,” “third-party citations,” and “hypotheses drawn from my own operational experience.” These categories will not be mixed.

Why the “Year of Running” Frame Lands

AI agent articles have been dominated by “how to build,” “tool comparisons,” and “case studies” for the past six months. As someone who writes this content — and who runs an autonomous workflow called Izumo using Claude Code and MCP servers — I haven’t shared much from the operations side. Today I’m fixing that.

IBM’s “year of running” framing rests on three observed facts.

First: a surprising number of companies failed to move from PoC (proof of concept) to production operation. Since the second half of 2025, multiple AI researchers and consulting firms have published analyses identifying “not infrastructure, but absent operations design” as the reason AI pilots fail to deliver results. This is an observation drawn from across the industry, not a single primary source.

Second: Anthropic published “Claude for Small Business” in May 2026 — 15 ready-to-run workflows aimed at small businesses (Anthropic official news, 2026-05-23). A clear signal of a transition from individually “building” agents to “running” what’s already available.

Third: HBR’s June 2025 feature argued that organizations aren’t ready for the risks of agentic AI — and that organizational readiness means observing agents, giving them feedback, and designing handoffs. Also an operations story. (“Organizations Aren’t Ready for the Risks of Agentic AI,” HBR, June 2025.)

Three different sources pointing the same direction. Building is done. Running has begun.

Here’s the critical distinction: “running” does not mean “set it and forget it.” AI agents degrade silently if left alone. Responses drift slightly. An external API changes one step and it fails. Input data patterns shift and output quality drops. The agent stops delivering value and nobody notices.

That’s the real obstacle facing people whose agents stalled at PoC. It’s less “it doesn’t run” and more “we have no awareness of running it.”

[[IMG:1]]

From here: what follows is framing built from my own hypothesis, developed through operating the Claude Code and Izumo system in production. This is not a direct quotation of IBM’s official language. Read it as “here’s how to translate IBM’s frame into practice for individual and small-team operations.”

3 Conditions for Getting an Agent into Sustained Operation

The 3 conditions I’ve arrived at: observability, iteration, and handover.

[[IMG:2]]

Condition 1: Observability — Being able to notice when it breaks

The most fundamental condition and the most commonly skipped. Log what the agent takes as input, what it outputs, and where it fails. Without this, operations can’t start on day one.

The first thing I built in Izumo was a mechanism to aggregate each agent’s execution logs into a single file. Four columns only: timestamp, input summary, output summary, error flag. That alone was enough to know “three agents ran yesterday, only two ran today.”

PoCs without observability share a common symptom: a state of “supposedly running.” Weekly reviews report “on track” — but when you open the logs, half the runs were failures. From my operational experience, operations without observability tend to collapse within three weeks. This is an experiential rule of thumb, not a quantitative study.

The follow-up question: “What tool do I use for observability?” Anything works at the start. A single file is enough. Tools like LangSmith or Langfuse (both LLM-specific monitoring tools) exist — but before you bring those in, start by writing a 4-column log file yourself. Depending on a tool means getting stuck on tool selection. That’s also from direct experience.

Condition 2: Iteration — Being able to fix it when it breaks

Observability without the ability to fix is useless. That’s condition two.

When an agent’s output quality drops, can you diagnose whether the problem is in the prompt, the model, the tools (external APIs), or the input data? If all you have is the output, any fix is a guess.

In my Izumo system, an agent called Masago runs 3-round feedback for each agent’s output. What matters is that the review feedback is retained along with the reasoning behind each note. A month later, when the same symptom reappears, I can search past reviews and find “this same problem appeared in March — the fix was a prompt revision.”

Without that, you’re doing root cause analysis from scratch every time. One agent is manageable. When you’re running 10 or 20, operations physically breaks down without an iteration record.

A one-page fix template is enough: 5 columns — symptom, observed metric, hypothesis, action taken, result. That’s it. Complex incident management tools can wait until the scale justifies them.

Condition 3: Handover — Being able to run it without you

The third condition and the most frequently skipped. When you’re the only person running an agent, the operations live entirely in your head.

In Izumo, I write a document I call a “Soul Document” for each agent: role, decision criteria, past failures, patterns to avoid. Anyone who reads it can understand the design intent of that agent without my involvement.

Without a handover document, an agent becomes a black box the moment its creator leaves. This isn’t a technical problem — it’s an organizational one.

The minimum Soul Document is 5 items: role, inputs/outputs, decision criteria, past failures, patterns to avoid. Keep each short. One page is enough. Details can be added later. Whether the first page exists or not determines whether an agent is an organizational asset or a personal tool.

[[IMG:3]]

The 3 symptoms of PoC stalling map directly to the 3 conditions: not noticing when it stops (absent observability), rebuilding from scratch when it breaks (absent iteration), and one person as a single point of failure (absent handover). One missing condition and the agent won’t stay in production. All three together is what “running” actually means.

Why the 3 Conditions Get Skipped

Hearing the 3 conditions, you might think “that’s all obvious.” I thought so too at first.

They get skipped for a simple reason: none of the 3 conditions feel necessary while you’re building. In the prototyping phase, the agent is right in front of you. You can see the output directly without checking logs. Fixes are a prompt edit away. Handover doesn’t matter yet — the team isn’t there.

The problem: when you decide to move from PoC to “real operation,” you discover that observability, iteration records, and handover documentation don’t exist. Starting all three from zero at that point is psychologically brutal. So it gets deferred. And the agent stays at PoC.

The fix: build the 3 conditions in from the start. That’s the essence of “the year of running.”

The Real Reason PoC Stalls

If you were expecting a “tool selection” discussion or a talk about prompt skill, this might be disappointing. But based on everything I’ve seen in actual production operations, the real reason PoC stalls is almost always the same: absent operations design.

Technical failures are almost always resolved with prompt adjustments or migrating to a different tool. The problem comes after. Without a system to keep running, three weeks later comes “wait, is that agent still running?”

A concrete example: I know of a marketing team that built a meeting summary agent using Claude Code. It ran smoothly for three weeks. In week four, Zoom updated its API spec for a specific meeting type, causing summaries to come back empty for that type. The team member didn’t notice. Three months later, the manager said “the summary quality seems to have dropped recently” — and that was when they discovered it had been broken the whole time.

What failed there wasn’t the technology. It was the operations. Without observability, an agent can run broken for three months with no one noticing.

This type of incident exists at every scale — small company, large enterprise. As agent count grows, unobserved operations become exponentially harder to manage.

For reference: I currently run 11 agents in my Izumo system. Without execution logs, I couldn’t even know “how many agents ran normally today” every morning. Monthly improvements would be pure intuition. Since adding logging, I can say each week “these two agents have degraded output quality this week” — in numbers. The quality of decisions is completely different. The difference comes from observability, not tool choice. Also an operational finding, drawn from 11 live Izumo agents.

Identifying Which Symptom Your PoC Has

Check which of the 3 symptoms applies to your agent:

1. In the past month, have you personally verified the output of that agent at least once? If no — observability is absent.

2. The last time your agent produced an unexpected output, could you diagnose which part to change in 5 minutes? If no — the iteration mechanism is absent.

3. If you were away for a week, would that agent keep running? Is someone else able to manage it? If no one can — handover is absent.

If even one of those catches you, operations design needs to go in. If all three catch you — stop the agent, rebuild the operations design, then restart. I’ve gone through this reset myself multiple times.

The One Design Flaw to Fix This Week

Fixing all 3 conditions at once isn’t realistic. So choose one to fix this week.

Fix observability — this week, without fail.

The reason is simple: without observability, neither iteration nor handover can function. Iteration requires logs to act on. Handover documentation is written based on the history observability provides. Observability is the foundation.

And observability is the lightest condition to implement. Start with a single file and 4 columns. No cloud contracts, no tool selection required. You can complete one full cycle within a week.

The follow-up: “What specifically do I log for observability?” Minimum configuration is 4 columns:

Column	Content
Timestamp	YYYY-MM-DD HH:MM format
Input summary	1–2 line summary of the input
Output summary	1–2 lines or output filename
Error flag	OK or NG; if NG, a brief note

That’s it. Don’t make it complex. Complexity kills the daily habit of logging, and operations stops. Simplicity is the point.

3 Actions to Start Within 7 Days

Concrete actions you can move on this week, in fixed order.

[[IMG:4]]

Action 1 (Day 1–2): Define one observability point

Build a mechanism to append the 4-column log after each agent execution. Do this in the first half of the week.

Concretely: add one line to the agent’s execution script — “append execution result to logs/agent-name.log.” One file. Spreadsheet or text file, either is fine. Pick a location and make sure it gets appended. If you’re using Claude Code, add “append execution log to logs/agent-name.log” as a single line at the end of the agent definition file. Under 30 minutes of work.

For the fundamentals of how AI agents are built, 3 Routes to Building AI Agents covers the foundation. The intended reading order: understand how they’re built, then add operations design.

Action 2 (Day 3–4): Create a fix template

Prepare one page with 5 columns: symptom, observed metric, hypothesis, action taken, result. Notion, Obsidian, a Markdown file — anything works.

In the first 3 days, if you notice any anomaly, write it into the template. If you can’t write anything, go back and check the execution log. There may not be enough observability data yet.

Action 3 (Day 5): Write the first page of the handover document

For each agent, write one page covering: what input it takes, what it outputs, what it prioritizes when uncertain. No detail required. Something you can write in 30 minutes.

In Izumo, I call this the Soul Document. As long as page one exists, someone other than me can understand “what is this agent for.” That’s sufficient.

Day 6–7: Run the first full cycle

With all 3 actions in place, run one full cycle on Day 6–7. Open the execution log, write any anomaly into the fix template, reflect the learning in the handover document.

Experiencing this one cycle once is what makes operations design internalize as your own habit. From the following week, run this cycle weekly. This is what “running” an AI agent actually means.

For those who want to understand Claude Code’s pricing and deployment costs, Claude Code Pricing — What It Actually Costs is a good reference. Understanding the budget picture before building out operations design makes it easier to project ROI.

Wrap-Up

AI agents have entered the “run” phase. Building is done. What comes next is operations design that keeps them running.

The 3 conditions one more time:

• Observability: being able to notice when it breaks. Start with a 4-column log.
• Iteration: being able to fix it when it breaks. Keep a history with a 5-column template.
• Handover: being able to run it without you. Start with a 1-page document.

If you fix one this week, fix observability. It’s the foundation — without it, iteration and handover can’t function. You can implement it in 30 minutes. Start this week.

An agent that was “built but not running” isn’t a failure of technical skill. It’s a missing operations design. Wire in the 3 conditions and a stalled PoC agent will start running.

“The year of running” has started. This week, write the first log line. That’s where it begins.