The ThruWire Pattern
As agents coordinate more of the customer’s job, your product needs to maintain the goals, judgments, artifacts, and dependencies that keep that job moving.
AI assistants increasingly coordinate work across software. Claude, Codex, and future agents can inspect records, use tools, create artifacts, and carry context from one product to the next.
When a product only exposes records and actions, the agent must reconstruct the customer’s goal, judgments, artifacts, dependencies, and next steps. That working context accumulates in the harness around the product.
The product that owns this work can own more of the outcome. The ThruWire Pattern gives it a durable home inside the product: a domain-specific working model agents advance and customers steer.
Customers can begin with an intent and let an assistant choose capabilities, cross application boundaries, and delegate work to specialized agents.
This creates a product decision: which work should remain transient agent context, and which work should become authoritative product state?
APIs, MCP tools, and retrieval let an assistant reach your product. The agent still has to relate the customer’s goals, judgments, plans, artifacts, and follow-through.
When those relationships exist only in prompts, transcripts, files, and harness memory, the product sees the actions but loses the working context that explains them.
A working model captures the current, connected state of the job: the goal, evidence, judgments, artifacts, dependencies, open work, actions, and observed outcomes.
The product defines the domain model. Each customer builds a unique instance through use. Agents maintain and advance it; the customer supplies the authority and direction that make it theirs.
The model becomes a product when structure, change, agent access, and customer authority work together.
Each interaction can leave the work in a better state: which evidence mattered, which assumptions the customer corrected, which actions were approved, and which results followed.
This customer-specific history of work and judgment is difficult to recreate from operational records alone. It gives the product better context for deciding what should happen next.
Memory, retrieval, wikis, and transcripts supply useful source material. A product still needs to know the current goal, the authority of a judgment, the dependency between artifacts, and what should change when new information arrives.
The working model makes state, relationships, lineage, versions, and update behavior explicit. It distinguishes current from historical and authoritative from merely available.
Established products already hold operational records, domain expertise, and the places where customers act. The working model connects those assets to judgments, intermediate artifacts, open decisions, dependencies, and outcomes.
Any capable agent can become an interface to that model. The product remains the authoritative place where the customer’s work accumulates, changes, and moves forward.
Customers experience one system. It understands their work, advances it, and makes every change legible. Data, Technology, and UX are how the product delivers that experience.
The AI assistant can change. The model provider can change. The interface can change. The customer’s working model remains inside the product, available to the customer and to whichever agent helps them next.
That is the ThruWire Pattern: own the work, then use it to own more of the outcome.