Wiro agent anatomy describes the eight moving parts that turn a request into work that can be checked, continued, and explained. This is not a model benchmark. It is an architecture walkthrough: the two figures below show the path a production agent follows, rather than two competing image or language-model outputs. That distinction matters. There is no model prompt, seed, temperature, runtime, or per-output cost recorded for either figure, so no such number is claimed here.
What this check set out to examine
The useful question is not whether an agent can produce a polished answer in one turn. It is whether it can handle the awkward parts of real work: a brief that leaves out a detail, a tool response that needs interpretation, a task that stretches across several steps, or a failure that should be repaired rather than silently abandoned.
This walkthrough checks the operating layers needed for that job. The test case is a typical business request: receive context, decide what to do, break the work down, use an appropriate tool, retain only the context needed for the next step, inspect the result, recover from a known failure mode, keep longer work alive, and leave a concise account for an operator. The aim is to make the handoffs visible, not to claim a single numerical score.
That framing matches the distinction in Anthropic’s guide to effective agents: workflows follow predetermined paths, while agents decide their process and tool use dynamically. Neither choice wins by default. A fixed workflow is often better for stable, well-defined work. An agent earns its extra moving parts when the route depends on what it sees along the way.
The 8 parts of Wiro agent anatomy
1. Reasoning
Reasoning decides what the request means in its current context. It identifies the goal, constraints, and the next useful action. It should not be treated as a license to improvise facts. Good reasoning turns uncertainty into a check, a question, or a bounded assumption.
2. Decomposition
Decomposition converts a goal into steps with clear dependencies. A lead follow-up, for example, may require checking the record, choosing a message path, creating a task, and reporting the result. Splitting those stages makes a failure easier to locate and a handoff easier to audit.
3. Skills
Skills give the agent a defined way to do domain work. They connect a decision to a real operation, such as reading a record, drafting content, or updating a system. Their value is restraint as much as reach: a narrow skill can set inputs, permissions, and expected outputs instead of asking a model to guess how a third-party system behaves.
4. Memory
Memory preserves useful state across turns. It can hold a prior decision, a customer preference, a completed step, or a known constraint. It should not become a dumping ground. The best memory is specific enough to help the next action and limited enough to avoid carrying irrelevant context forward.
5. Self-review
Self-review asks whether the result meets the task before it is treated as complete. The check can be simple: did the requested field change, did the output match the required format, and did a citation or attachment survive? Review is not proof of correctness, but it catches many avoidable misses before a human sees them.
6. Self-heal
Self-heal is a bounded recovery path. A stale reference can be refreshed, a malformed tool response can be re-read, and a missing prerequisite can be obtained before retrying. It should not mean endless retries. A responsible repair path has limits, preserves the original goal, and escalates when the needed decision belongs to a person.
7. Heartbeat
Heartbeat keeps longer tasks from disappearing between steps. It gives a run a deliberate chance to continue or check back at a useful interval. This matters when an operation waits on an external system, a scheduled window, or another stage of the workflow.
8. Recap
Recap turns a long execution trace into an operator-readable result: what changed, what did not, and what needs attention. It is the layer that prevents an agent from being a black box after it has touched real systems.
What the two figures actually show
Figure 1 is the front half of the operating loop. A request enters the system, reasoning interprets it, and decomposition chooses a sequence of bounded actions. The important point is that tool use comes after a decision about the job, not before it. A skill then performs the selected operation with the inputs and constraints that task requires.
Figure 2 covers the part that short demos often omit. Memory carries useful context forward. Self-review checks the result against the requested outcome. Self-heal provides a controlled response when an input, reference, or tool call does not behave as expected. Recap then exposes the outcome to the operator. Together, those layers turn a one-off response into a process that can be inspected.
Parameters, run time, cost, and limits
This post does not document a model invocation behind either visual. The existing media are architecture illustrations hosted on this blog, not labeled outputs from a named Wiro model. For that reason, the test parameters are the workflow conditions above: multi-step work, tool use, retained context, a review point, a recoverable failure, a continuation mechanism, and an operator-facing recap. There is no disclosed prompt, model name, resolution, token setting, run duration, or per-output cost for the figures.
Leaving those fields blank is intentional. A run time or cost without a recorded run would be made up, and it would make a platform architecture page look more precise than it is. If a team needs a performance comparison, it should run a fixed task set with a named model, the same inputs, a documented success rule, and recorded elapsed time and cost for every attempt. The research paper Executable Code Actions Elicit Better LLM Agents is useful context for tool-using agents, but its benchmark results should not be treated as a measurement of this Wiro architecture.
The same caution applies to the word “self-heal.” Recovery can improve reliability, but it cannot fix every missing permission, ambiguous business rule, or incorrect source record. A good system stops and surfaces the blocker when retrying would create risk or repeat the same mistake.
When to choose an agent instead of a fixed workflow
Choose a fixed workflow when the steps are stable, inputs are predictable, and a human has already decided every branch. It is easier to test and usually cheaper to operate. Choose an agent when the task requires interpretation between steps: sorting a messy request, selecting from several allowed tools, reconciling a partial response, or carrying context through a longer interaction.
A practical rule: start with the smallest system that can do the job. Add decomposition when work has dependencies. Add skills when the task touches real systems. Add memory when a later decision depends on an earlier one. Add review and recap when a mistake needs to be caught and understood. Add self-heal only for known, safe repair paths.
For examples of those tradeoffs in practical operations, see How AI Agents Work for Business Teams, AI Agent Retry Logic: 6 Rules for Jobs That Fail Mid-Workflow, and AI Agent Audit Trails: 7 Things Teams Need to Log.
Bottom line
Wiro agent anatomy is a checklist for evaluating the work around a model, not a claim that one model call solves every business process. Reasoning, decomposition, skills, memory, review, recovery, heartbeat, and recap each cover a failure point that appears once work becomes multi-step and connected to real systems. Explore the operating model on the Wiro Agent Anatomy page.
