The AI Agent Capability Map: Reasoning, Memory and Action | MewCP
The AI Agent Capability Map
by Rohit Gite, Co-Founder CTO @MewCP··21 min read
Most people building agents pour their effort into one third of the system. Better prompts, deeper chain of thought, a stronger model. Then the thing produces a flawless nine step plan and nothing in the world is different. Here is what reasoning, memory and action each own, where they belong in a real codebase, and what breaks when one quietly takes over another's job.
Reasoning, Memory and Action, and Where Each One Lives
Companion resource to Day 05 of 30 Days of AI Agents · MewCP · @mewcp_ai
Before you start
The carousel covered what the three capabilities are. This guide is for the two questions that show up about ten minutes after that lands:
Where do these things actually live in my codebase?
What breaks when one of them quietly takes over another one's job?
Read the first section once to get the vocabulary straight. After that, treat Section 2 as the wall chart, Section 3 as the thing you open when something is going wrong, and Sections 5 and 6 as the reference you keep coming back to while you build.
None of this is tied to a framework. It applies whether you wrote your own loop, you are using a graph library, or you are on a hosted runtime. Where a recommendation genuinely depends on your stack, I have said what the trade off is rather than picking for you.
One line to carry through the whole document:
Reasoning decides. Memory makes the decision right. Action is the only part that changes anything.
Section 1: The three capabilities in depth
Reasoning:
What it owns
Reasoning owns choosing what to do next when the answer is not obvious. Given a goal, the current observation, and whatever memory handed it, reasoning picks the next move. It also decides when to stop, which people forget is part of the same job.
That is a narrower remit than most builds give it. Reasoning owns:
Turning the goal into something you can act on
Choosing the next step from the options available
Reading an observation as success, failure, or "keep going"
Calling the run complete, or calling it impossible
What it must never own
Durable state. The moment reasoning is responsible for remembering, every run pays to work out again what a lookup could have handed over for free.
Effects. Reasoning that "performs" an action is reasoning that invents outcomes. The model's job stops at intent.
Authorisation. Whether an action is allowed is a property of the action layer. A prompt that says "only do this if permitted" is a suggestion. It is not a control.
The smallest version that counts
One model call. It receives the goal, the current observation, and a list of available actions. It returns a single structured next step with a reason. That is a complete reasoning layer.
Not a planner, not a critic loop, not three models arguing. Those are refinements, and none of them help you if memory and action are thin. Most teams reach for them far too early.
Signs it is underbuilt
The agent repeats a step because nothing told it the last attempt failed
It cannot stop. It either runs to the step cap or gives up at the first ambiguity
Step choice is effectively hard coded and the model is just formatting output
Failures produce a retry rather than a diagnosis
Signs it has swallowed something else
It has taken over memory when the prompt has grown to hold facts that should be looked up, and it grows again every time a new edge case turns up.
It has taken over action when the model returns text describing a completed action instead of a request to perform one. "I have updated the config" with no call behind it is the classic version.
Memory:
What it owns
Memory owns relevance over time. Its job is not to store things. Storage is the easy part. Its job is to answer one question before reasoning starts: of everything that has ever happened, what matters to this task, right now?
Memory owns:
Keeping facts, outcomes and decisions past the end of a run
Selecting the small subset that bears on the current step
Carrying state inside a run, so step seven knows what step three learned
Recording what was tried and what it cost
What it must never own
Decisions. Memory supplies, it does not choose. A retrieval layer that filters results by "what the agent ought to do" has quietly become a second reasoner, with none of the first one's visibility.
Everything. Memory that never forgets is a log. Retention is part of the design, not something you bolt on later.
Deciding which fact is true. When two remembered facts conflict, memory hands over both with their timestamps. Reasoning sorts it out.
The smallest version that counts
A keyed store, which can be a table, a JSON file or a dictionary, plus one function: recall(task) returns facts.
Even a hand written rule counts. "If the task mentions a deploy, fetch the last three deploy outcomes" is real memory, because it selects. The selection is the capability. The database is not.
Signs it is underbuilt
The agent starts from zero on every run
It tries an approach it already tried and failed an hour ago
Users find themselves supplying the same context they supplied last week
Cost per run stays flat no matter how much the agent has already learned about the task
Signs it has swallowed something else
It has taken over reasoning when retrieval has grown scoring rules, priority overrides and special cases, until the real decision is being made inside the retrieval function where nobody looks.
It has taken over action when the memory layer writes to systems other people read. Updating a ticket "so we remember it" is an action, and it belongs on the action side of the line where it can be audited and undone.
Action
What it owns
Action owns external effect. Reading the file. Calling the API. Sending the message. Writing the row. If nothing outside the model is different, nothing happened.
Action owns:
The catalogue of what the agent can actually do
Running a requested step against the real world
Returning an honest observation, including failures
Enforcing permission, rate limits and blast radius
Making effects reversible where reversal is possible
What it must never own
Step choice. A tool that decides whether it should run has taken reasoning's job somewhere nobody can inspect it.
Silent failure. An action that swallows an error and returns something plausible poisons every decision downstream. The observation has to be true, and that includes "this did not work."
Unbounded scope. "Run arbitrary code" is not an action. It is the absence of an action layer.
The smallest version that counts
A typed function with a name, a described purpose, validated inputs, and a return value that distinguishes success from failure.
Three or four of these beat twenty vague ones. The description is part of the interface, because it is what reasoning selects against. Badly described tools produce badly chosen steps, and it looks like a model problem when it is really a documentation problem.
Signs it is underbuilt
Beautiful plans, no results. This is the Day 05 failure exactly
Real work still needs a human to carry out the steps
Tools exist, but they are scoped so broadly the model misuses them
There is no way to check whether an action actually took effect
Signs it has swallowed something else
It has taken over reasoning when a tool branches internally on a fuzzy input, and that branching logic has quietly become policy nobody wrote down.
It has taken over memory when a tool caches results and hands back stale data without saying so, which hides state from the layer that should own it.
Section 2: The map
This is the page to pin up. It is drawn so it can be read on its own, without the text around it.
The three hand offs
Memory to reasoning: selected facts. Not the store, not the transcript. A small, ranked set of things that bear on this task. If this hand off is carrying everything, memory is not doing its job, and reasoning is paying for that in tokens and confusion.
Reasoning to action: intent. A named step with validated arguments. The important property of this edge is that it carries a request, not a result. Reasoning does not know whether the step worked until the observation comes back.
Action to reasoning: observation. The truth about what happened, failures included. This edge is what closes the loop. An agent missing it is a plan generator with good manners.
Action back to memory: outcome. What was attempted, what it cost, what came of it. This is the edge most first builds leave out, and its absence is the reason an agent that ran yesterday is no smarter today.
Action to the world. One capability touches the world, and only one. That single property is what makes an agent auditable, testable and safe to bound. Protect it.
Section 3: Capability bleed, and the four ways it shows up
Capability bleed is what happens when one capability quietly takes over part of another one's job. It is the most common structural fault in a first agent build, and you usually cannot see it until it has already cost you something.
Each one below is written as: what you actually observe, what the underlying boundary violation is, and the smallest change that fixes it. The smallest change matters. These are not rewrites.
Reasoning doing memory's job
What you see. The system prompt keeps growing. Every new edge case adds a paragraph. Runs cost more than they should and behave slightly differently each time. Someone has started a document called "things to add to the prompt."
What is actually wrong. Facts that should be fetched on demand are riding along on every single call, relevant or not. Because they live in the prompt, changing one means a deployment.
Smallest fix. Take the most volatile block in the prompt, usually the one holding specific IDs, facts or recent history, and move it behind a recall(task) call. One block. Measure the token change and the failure rate. This is a twenty minute change that normally pays for itself straight away, and it makes the next block obvious.
Action hiding in the prompt
What you see. The model claims it did things. The logs show a confident narrative and no matching API calls. Behaviour shifts when someone edits the wording of the prompt, and nobody can explain why.
What is actually wrong. The rules about what may be done, to what, and under which conditions are living in natural language, where they cannot be tested, meaningfully versioned or enforced.
Smallest fix. Find the one instruction in your prompt that reads like a rule with consequences. "Never delete anything in production." "Only email addresses on the approved list." Implement it as a check inside the tool. Leave the sentence in the prompt if you want. The difference is that now it is enforced somewhere the model cannot talk its way past. Repeat, highest consequence first.
Memory reduced to a transcript
What you see. The context window fills up. Quality drops off partway through longer runs. The fix keeps being summarisation, and the summaries keep losing the one thing that mattered.
What is actually wrong. Memory has become storage with no selection step. Appending everything is not memory. It is the absence of memory, and you are paying for it in tokens.
Smallest fix. Put one selection step in front of the transcript. Given the current task, return at most N prior items. Start crude: same entity, same error class, last few occurrences. Crude selection beats no selection by a wide margin, and it gives you somewhere to put a better retrieval strategy later without restructuring anything.
Everything in one call
What you see. One enormous prompt doing retrieval, decision and execution instructions together. When it fails, nobody can say which part failed. Evaluation is impossible because there is only one output to grade.
What is actually wrong. All three boundaries have collapsed into each other. This is the anti pattern that generates the other three, and it is very common in prototypes that became production without anyone deciding they had.
Smallest fix. Pull the observation out first. Have the call return a structured intent, run it in code, feed the real result back in. That one split turns a monologue into a loop, and it is usually the change that turns a demo into an agent. Pull memory out second, once you have a loop to hang it on.
Section 4: Memory is not context
This is the distinction that catches nearly everyone, including me, for longer than I would like to admit.
Context is what you put in the window on this call. Memory is what works out which things are worth putting there.
Stuffing the whole history into every prompt is not memory. It is what you do instead of memory, and the bill arrives as tokens, latency and a model whose attention is spread across four thousand irrelevant lines. Real memory selects. It answers "what from before is relevant to this task" before reasoning ever starts.
In the staging example from the carousel, memory did not recall everything that ever happened to that service. It surfaced the one prior incident that changed the plan. That is the whole capability in a sentence.
Three ways to do retrieval, cheapest first
Rule based recall
A hand written function keyed on the shape of the task. If the task references a deploy, fetch the last three deploy outcomes for that service.
Costs you an afternoon. Completely predictable, trivial to debug, no infrastructure. Brittle at the edges, and every new task shape needs a new rule.
Use it when your agent has fewer than a dozen or so recognisable task types. That covers far more real systems than people expect. Skipping straight past this to a vector store is the most common piece of over engineering in the whole space.
Structured query
Facts stored as rows with real fields: entity, event type, outcome, timestamp. Retrieved with an actual query.
Costs you a schema and about a week of iteration. Precise, filterable, sortable by recency, cheap to inspect and correct when it is wrong. The limit is that you have to know what the fields are in advance, so genuinely novel recall is out of reach.
Use it when your domain has stable nouns: services, customers, tickets, repositories. Most engineering workflow agents belong here and never need anything more.
Semantic retrieval
Embeddings over prior episodes, retrieved by similarity, usually re ranked.
Costs you an embedding pipeline, a store, a re ranker, and a relevance problem that does not stay solved. It handles open ended recall and phrasing you did not anticipate, which is real value. It is also the hardest to debug, because when the wrong thing comes back there is often no legible reason why, and it degrades quietly without a freshness and eviction policy.
Use it when the space of relevant prior episodes is genuinely open ended, and you have already confirmed that a structured query cannot reach it. Put it behind a structured filter rather than in place of one.
When a transcript is genuinely fine
Sometimes it is, and pretending otherwise wastes a week.
Append the transcript and move on if all three of these hold: the run is short and the whole exchange fits with room to spare, nothing needs to survive past the end of the session, and it is one user with one task in one sitting.
The mistake is not using a transcript. It is using one past the point where it stopped working, and reaching for summarisation instead of selection. When you catch yourself compressing history to make it fit, that is the signal to build the selection step.
Section 5: Where each one lives
There are four places anything can live: the prompt, code, storage, or behind an interface. Where you put something is a design decision with real consequences, not a convention.
Capability
Prompt
Code
Storage
Interface
Reasoning
Goal framing, selection criteria, stop conditions
The loop, step cap, structured output parsing
nothing
Model endpoint
Memory
Nothing durable, only the selected facts, injected per call
The recall() selection logic
Facts, outcomes, embeddings
Retrieval service, if shared
Action
Tool names and descriptions only
Validation, permission, execution, error mapping
Audit log of effects
The tools themselves
The reasoning behind that table:
Put in the prompt only what the model has to weigh up. Goal framing, guidance on trade offs, stop conditions, tool descriptions. Everything in the prompt gets paid for on every call, and it is enforced by nothing at all.
Put in code anything with a consequence. Permission checks, rate limits, validation, retries, the loop itself. Code is testable, versioned, and does not negotiate. If breaking a rule would be an incident, that rule does not belong in prose.
Put in storage anything that has to outlive the run. Facts, outcomes, costs, and the audit trail of what the agent actually did. Decide retention on purpose: what expires, what gets corrected, what is never deleted.
Put behind an interface anything with an external dependency or more than one consumer. A retrieval service used by three agents. A tool wrapping a third party API. The boundary buys you the ability to mock it in tests, which is what makes the agent testable at all.
There is a real trade off here and it is worth naming. Moving logic from the prompt into code buys you determinism and costs you flexibility. Every rule you harden is a rule the model can no longer adapt around when reality turns out to be shaped slightly differently from your assumptions.
The heuristic I use: harden by consequence, not by frequency. Rules whose violation is expensive or irreversible go into code immediately, even if they almost never fire. Rules that are merely usually right can stay in the prompt, where revising them costs nothing.
Section 6: Three tasks, worked end to end
Three examples, chosen to cover a read only task, a task that writes, and a task where the correct behaviour is refusing to act.
A read only task: why is the checkout page slow this week?
Step
Capability
What happens
1
Memory
Recall prior latency investigations on checkout. One comes back: three months ago, an N+1 query introduced behind a feature flag.
2
Reasoning
With that fact in hand, the first probe is recent flag changes rather than generic metrics. Memory has changed the starting point.
3
Action
Query the metrics API and the flag change log. Both read only.
4
Reasoning
A flag went on Monday, latency stepped up on Monday. That is enough. Stop.
5
Action
Post the finding to the investigation channel.
6
Memory
Record it: checkout latency, flag related, second occurrence.
Two things worth noticing.
Step 5 is an action even though it only posts a message. It changes something outside the model, so it lives in the action layer and gets the same permission and audit treatment as everything else.
Step 6 is what makes the third occurrence cheap. An agent with no write back edge starts from zero next time, and you will not notice, because it still works. It is just slower and more expensive forever.
A task that writes: staging is broken, fix it
The carousel example, in full.
Step
Capability
What happens
1
Memory
Recall prior staging failures. Last time it was a stale env var after a secret rotation.
2
Reasoning
Check the config before the build. Without that fact, the default plan starts with the build, which is the wrong end, and burns three steps getting back.
3
Action
Read the staging config. Read only, no permission gate needed.
4
Reasoning
The env var is stale, matching the remembered pattern. Next step: correct it.
5
Action
Write. Permission checked because staging is on the allowed environment list, value validated, prior value captured for rollback, effect logged.
6
Action
Redeploy. Bounded to one environment, one service, with a timeout.
7
Reasoning
Health check is green. Goal met. Stop.
8
Memory
Record it: staging failure, stale env var, second occurrence, time to resolve.
The safety in this run lives entirely in step 5, in code. The prompt never had to say "be careful with production," because the tool cannot reach production. Its allowed environment list does not contain it. That is the difference between a suggestion and a control.
The intelligence lives in step 2, and it did not come from a better model. It came from a fact that arrived before the model was asked to think. That is the argument of Day 05 compressed into one row of a table.
A task it should refuse: the customer is furious about a billing error, sort it out
This is the most important of the three, because the correct outcome is not to act.
Step
Capability
What happens
1
Memory
Recall this customer's history: two prior billing disputes, one escalated, enterprise contract.
2
Action
Read the invoice and payment records. Read only.
3
Reasoning
The discrepancy is real, but fixing it means issuing a refund, which is a financial effect on a contract with negotiated terms.
4
Reasoning
Check the available actions. issue_refund exists but is scoped below a threshold this exceeds. Stop condition met: cannot proceed.
5
Action
Escalate. Send the account owner a summary with findings, evidence and a recommended resolution.
6
Memory
Record it: escalated, threshold exceeded, third dispute for this customer.
Step 4 is not the agent being cautious. It is the action layer having a bound that reasoning can see and respect. If that threshold lived only in the prompt, a sufficiently upset customer message could talk the model straight past it. Because it lives in the tool's scope, it holds regardless of what reasoning concludes.
Escalation is an action, which is the second thing worth sitting with. Refusing to issue the refund does not mean doing nothing. The correct external effect here is a message to a human, executed and logged like any other action. An agent whose only failure mode is silence is an agent nobody will trust with anything.
And step 6 recording "escalated" rather than "failed" is what lets a human spot the pattern by the third occurrence. Memory of the things you did not do is still memory.
Section 7: How this fits with the six capabilities from Day 04
Day 04 laid out six capabilities of autonomy. This one gives three capabilities of the agent itself. They are different cuts, not competing lists. The six describe the control loop. The three describe what the loop is made of.
Day 04 autonomy capability
Owned by
Goal interpretation
Reasoning
Next step selection
Reasoning
Context retention
Memory
Tool use
Action
Observation and correction
Action produces it, reasoning consumes it
Stop conditions
Reasoning decides, action enforces the hard bounds
Read that table one way and it tells you which layer to open when an autonomy behaviour is failing. Read it the other way and it tells you which behaviours you lose when one of the three is thin. The second reading is the one that catches problems before they happen.
