A Correct AI Answer Can Still Be an Unusable Workflow

An extracted price is only useful if someone can compare it with the next supplier's offer. An edited sentence is only useful if it lands on the right page. Those sound like ordinary software requirements. They are also where an AI feature starts becoming a working system.

Disclosure: This article was researched and drafted with AI using my public project documentation and the linked technical sources.

Looking across my pricing, editing, and archive-search projects, I see a recurring design question: what has to be true before a model's output can become something another person relies on?

Conceptual diagram generated with AI-written drawing code, based on public project documentation.

The price needs somewhere to go

In my TMC pricing project, supplier information arrived through emails, lists, and attachments. The workflow extracted product, size, price, region, and supplier into structured records for comparison. An early prototype used DeepSeek R1 for interpretation.

Extraction was one stage. The wider work included a central pricing repository, reviewable reports, and quote and invoice workflows. The public case study describes a delivered 2023–2025 engagement; it should be read as project history, not a fresh benchmark of today's models.

The useful unit here is a comparable pricing record. If two offers describe different sizes or regional contexts, putting their prices beside each other does not settle the comparison. A fluent extraction can still leave the operational question unresolved.

For a similar system, I would evaluate the handoff explicitly: can a reviewer trace the extracted value to its source, understand the product description, and see what remains uncertain? Those are proposed evaluation questions, not additional features or measured results claimed for this project.

A paragraph belongs to a particular version

My Okeike editor approaches a different problem: making focused changes to existing websites. It combines recoverable drafts, AI-proposed edits, and publishing through GitHub commits and the existing Firebase deployment path.

Its patching layer uses constrained selectors and structured fields. Source-version fingerprints and base-file identifiers help recognize when the file underneath a draft has changed. Static HTML and structured application content have different patching paths.

That detail matters more than whether the suggested sentence reads beautifully. A proposed edit needs a target and a source version. Otherwise, a correct sentence can become an incorrect change.

This also gives review a manageable scope. Someone can inspect a focused patch without reconstructing why an entire page was regenerated. The editor remains under development; a working publication path is different from claiming every client workflow is finished.

An archive answer needs its surrounding record

For Illumia's archive tool, I built around the relationship between service cases and their work entries. Search results preserve the parent case context, so a matching note can be understood within its history.

The Claude Desktop connection exposes six bounded, read-only retrieval tools. Counts and totals come from database queries. The assistant does not receive arbitrary SQL or write access, and the browser and assistant share the retrieval service.

The implementation was tested with synthetic records. Actual archive relevance checks and workplace acceptance are separate steps. Keeping that distinction visible is part of describing the system honestly.

This example changes the evaluation target again. An answer can quote a real note and still mislead if it leaves out the later work that resolved the issue. Retrieval quality includes preserving enough context for a person to check the interpretation.

Why this matters as agent tooling expands

GitHub's October 12, 2026 guide to teaching Copilot about a codebase separates repository instructions, repeatable skills, custom agents, and MCP connections. That is useful context for the current move toward agents embedded in existing development workflows.

My reading is that these layers make the surrounding system increasingly important. Instructions describe conventions. Tools expose capabilities. The application still needs to decide which state changes are valid and how their results can be checked.

Anthropic's April 2026 Managed Agents engineering article makes a related architectural point at infrastructure scale: session history, the agent loop, and execution environments can be separated so components can fail or be replaced independently. That is a vendor's architecture account, not evidence that every application needs the same infrastructure.

For smaller teams, the practical implication is more modest: define the handoff before adding more autonomy. Specify the record being created or changed, the evidence that supports it, and what happens if the source changes or the action fails.

There is a cost. Version checks, review screens, and durable records add implementation work. Too much review can also recreate the manual process the automation was supposed to improve. The right boundary depends on the consequences of a mistake and how easily someone can recover.

In a project review, I would ask someone to follow one output all the way to its destination. Find the supplier offer behind the price. Locate the page version behind the patch. Open the case history behind the answer. The point where that trail breaks is a concrete place to improve the system.