DEV Community: obiwale ayomide

The Anatomy of an AI Agent: Five Parts and the Framework That Wires Them Together

obiwale ayomide — Mon, 07 Sep 2026 23:02:12 +0000

Ask a language model to book you a table for six this Thursday and it will do something quietly maddening. It will explain, fluently and with total confidence, exactly how one might book a table for six this Thursday. Then it will stop. Articulate, helpful, and unable to lift a finger.

That gap between knowing and doing is the whole difference between a chatbot and an agent. And the reason for the gap is blunt: a language model can only ever produce text. It cannot click a button, run a program, remember yesterday, or wait for your approval. So an agent is not a smarter model. It's a model surrounded by parts that cover what it can't do — and, just as importantly, a framework that wires those parts together and runs them.

That second half is the part most explanations skip. You can read ten articles listing "the components of an agent" and still have no idea how they actually connect. So here's the plan: meet the five parts, then meet the thing that binds them. If the parts are organs, the framework — LangChain being the best-known — is the nervous system that turns a pile of organs into a body that can act.

1. The Brain: the LLM

At the center sits a large language model, the same family of technology behind ChatGPT and Claude. This is where understanding and judgment live. It reads the request, thinks it through, and decides what should happen next. By a wide margin, it is the smartest thing in the room.

It also cannot do a thing. Left alone, the model — whether it's OpenAI's GPT, Anthropic's Claude, Google's Gemini, Meta's Llama, or Mistral — is the brilliant colleague locked in a room with no phone. On each turn it does exactly one thing: it's handed the story so far as text and asked "what next?", and it replies with either a finished answer or a request to use a tool. It never acts. It only decides and describes. Everything else in this article exists to carry those decisions out into the world and bring the results back — and the framework is what does the carrying.

2. The Hands: skills and tools

Tools are the specific abilities you bolt onto the model: search the web, run code, send an email, query a database. Each is a door from thinking into doing.

But notice the problem — the model can't open a door, only ask for one. This is the first thing the framework does for you. You write an ordinary function and describe it in plain language; the framework advertises that description to the model as an available tool, and when the model replies "call search_web with query: ramen near Shibuya," it's the framework, not the model, that runs the real function and feeds the result back. Your tools sit on one side; the model only ever names them; the framework is the hand that reaches between. The reach of an agent is whatever is on that menu — for a sense of how much can be, browse a collection like this catalog of AI agent tools.

3. The Notebook: memory

Here's a fact that surprises people: the model remembers nothing between turns. Each call starts cold. So the "story so far" it reads every turn has to be handed to it, fresh, every single time — and holding that story is another of the framework's jobs.

The framework keeps a running transcript of the task: your request, each tool the model called, each result that came back. Before every turn it re-injects that transcript so the model can pick up where it left off. That's short-term memory, and it's why an agent's second step can build on its first instead of forgetting it. Long-term memory is the same idea stretched across tasks — facts worth keeping, like your preferences, stored outside the conversation and pulled back in when relevant. When an agent "knows" a teammate is vegetarian, the framework fetched that fact and dropped it into the transcript so the model sees it as if it always knew. Without this thread, every turn is déjà vu.

4. The Strategist: planning

Give a capable person a shapeless goal and the thing standing between them and paralysis is a plan. Planning turns "organize the team offsite" into a sequence: find venues, check dates, draft an invite, send it once you've approved.

In an agent, planning isn't a separate box that fires once. It's that "what next?" decision, made again on every turn — reason a little, pick a tool, read the result, reason again. (You'll see this pattern named ReAct, for reason and act.) And the reason it can happen repeatedly is the framework: it's the framework that loops back to the model after every tool result and asks "what next?" once more, so the model can adjust — rerouting when the first restaurant turns out to be fully booked, because nothing is hard-coded and the next move is decided fresh each pass. Planning is what turns a pile of tools into a route; the framework is what lets the route be drawn one step at a time.

5. The Co-pilot: human in the loop

The last part is the one most often left off the diagram, and the one you'd miss the most: you.

Its place in the machine is exact. Remember the hand-off — when the model asks for a tool, the framework runs it. Human-in-the-loop is a checkpoint the framework enforces on that step. For anything cheap and reversible, like a search, it runs the tool and moves on. For anything that spends money or can't be undone, like book_venue, the framework pauses before executing, surfaces the pending call — "ready to book the $1,200 venue for Thursday, shall I go ahead?" — and waits. Approve and it runs; decline or edit and your reply becomes the next line in the transcript, which the model reads and adapts to. You're not watching from outside. You're a conditional step the framework fires only on the moves that carry weight.

The framework: the wiring that makes it an agent

Line the five parts up and you still don't have an agent. They don't touch. A model can't run a tool; a tool can't recall the transcript; the transcript can't decide what to do next; you can't approve a call nobody surfaced to you. Something has to connect them — pass each part's output to the next, and keep the whole thing moving. That something is the framework, and its role comes down to five concrete jobs:

One voice to the model. It wraps whatever LLM you pick behind a single interface, so swapping Claude for Llama doesn't ripple through your code.
A registry of tools it can run. It turns your described functions into the menu the model sees, and executes the real function when the model names it.
Custody of memory. It stores the transcript, fetches long-term facts, and re-feeds the right context every turn.
The loop. This is the engine room. It assembles the context, calls the model, reads the reply, runs a tool if asked, appends the result, and goes again — until the model returns an answer instead of a tool call.
Gates for humans. It's where the pause lives, stopping before sensitive tools to wait for your yes.

In practice you declare the parts and let the framework run the loop. In LangChain-flavored pseudocode, assembling an agent looks about like this — recognizable whether you end up using LangChain, LlamaIndex, or CrewAI, because they're all doing the same thing:

# 1. THE BRAIN — one interface over any model
llm = ChatModel("claude")            # swap for gpt / llama; nothing else changes

# 2. THE HANDS — plain functions; the framework runs them when the model asks
@tool
def search_restaurants(area: str) -> list: ...
@tool
def check_calendar(people: list) -> dict: ...
@tool
def book_table(place: str, time: str) -> str: ...

tools = [search_restaurants, check_calendar, book_table]

# 3. THE NOTEBOOK — the framework stores & re-feeds the transcript
memory = ConversationMemory()

# 4. THE STRATEGIST + 5. THE CO-PILOT — wired into one runnable loop
agent = create_agent(
    llm, tools, memory,
    require_approval=[book_table],   # human gate on the irreversible tool
)

agent.run("Organize a team lunch for six of us next week.")

Look at what you didn't write: the loop. You never wrote "call the model, parse its reply, run the tool it named, save the result, ask again." That loop is precisely what create_agent builds and agent.run executes — the framework's core job. Underneath, it's this small:

history = memory.load()                    # the notebook
while True:
    reply = llm(history, tools)            # brain + strategist: decide
    if reply.is_answer:
        return reply.text                  # nothing left to do — stop
    if reply.tool_call in require_approval:
        wait_for_human(reply.tool_call)    # co-pilot: the gate
    result = run(reply.tool_call)          # hands: the framework runs it
    history += [reply.tool_call, result]   # notebook: remember both
    memory.save(history)

Now watch the team lunch flow through it, with the framework as the thing doing the connecting. You hand it the goal; it starts the transcript. It calls the model, which — reading the goal — asks for search_restaurants; the framework runs that function and appends the options. It calls the model again with the longer transcript; now the model asks for check_calendar, and while wiring the result back in, memory adds that Priya can't do Mondays, so the model narrows to a workable day. The model settles on a place and asks for book_table — but that tool is gated, so the framework stops and asks you first. You say yes; it runs the booking, appends the success, and calls the model one last time. This turn the model returns not a tool call but an answer: booked, Thursday 12:30, vegetarian options sorted. Every arrow in that story was the framework taking one part's output and handing it to the next.

Not just LangChain

LangChain is the common entry point, but the same shape shows up everywhere. LangGraph (its graph-based sibling) models the loop as an inspectable, resumable state machine; LlamaIndex leans toward retrieval and memory; CrewAI orchestrates crews of cooperating agents; and the model-makers ship their own kits — OpenAI's function calling, Anthropic's tool use — that give you the tool hand-off directly. They differ in flavor and ambition, but under the branding each is doing the five jobs above.

Which means a new framework stops being intimidating. You can size any of them up with three questions: where does it keep the transcript, how does it describe tools to the model, and where does it let a human step in? Answer those and you know how it connects the parts.

Where this leaves you

Nothing here asks the model to be magic. It only produces text — it decides and describes, one turn at a time. Everything that makes an agent feel like it's doing things is the framework wrapped around that text: advertising tools and running them, carrying the transcript in and out, looping back for the next decision, and pausing at the gates that matter. The model is the engine; the framework is the rest of the car, and the five parts are what it connects.

So the next agent you meet gets much easier to read. The question stops being "how does the model work" and becomes sharper and more practical: what's on its tool menu, what's in its transcript, and where does it stop to ask?

If you've built or leaned on one of these, I'm curious which part you think most frameworks get wrong. My money is on the last one.

Delivery vs Payment (DvP): How CRE Solves the Hardest Problem in Finance

obiwale ayomide — Tue, 17 Mar 2026 16:12:28 +0000

Recently, I wrote about

CRE: The Missing Coordination Layer Between Traditional Banking and Blockchain.

It's time to go deeper because coordination alone isn’t enough. The real problem has always been settlement.

The Problem: Settlement Risk

At the core of every financial transaction is a simple requirement:

When one party delivers an asset, the other must pay.

This is known as Delivery vs Payment (DvP).
Asset transfer ↔ Payment transfer

Both must happen together or not at all. If they don’t, one party takes on risk.

Why DvP Breaks in Modern Systems

DvP works well inside a single system. But today’s financial world is fragmented across:

Banks
Blockchains
Custodians
Payment networks

Now consider this:
Asset → Exists on a blockchain Payment → Exists in a bank ledger

Two completely different systems.

The real question becomes:

How do you guarantee both sides settle atomically across systems that don’t trust each other?

Before CRE: The Workarounds
The industry had previously resorted to the following before the emergence of solutions such as Chainlink Runtime Environment (CRE):

Intermediaries: Dependent on intermediaries such as clearing houses and custodians to facilitate trust between two parties
Time Delays: Time periods such as T+2 reduce risks
Manual Reconciliation: Systems reconcile transactions after the fact.

All of these introduce:

Counterparty risk
Operational complexity
Capital inefficiency

Why Blockchains Didn’t Fully Solve This

Blockchains introduced atomic settlement, but only within their own environment and it works perfectly.
Token A ↔ Token B (same chain)

But:
Token (on-chain) ↔ Cash (in a bank)

This is broken because blockchains cannot:

Access bank systems
Trigger external payments
Guarantee off-chain execution

Enter CRE: A New Settlement Primitive
Chainlink Runtime Environment (CRE) introduces:

Programmable, verifiable workflows across on-chain and off-chain systems

Instead of forcing everything onto one chain, CRE connects:

Smart contracts → Chainlink Runtime Environment → External systems (banks, APIs, other chains)

This approach enables a cross-system atomic settlement

A Real Example: Cross-System DvP in Action

Recently,
Chainlink,
JPMorgan Chase (via Kinexys), and
Ondo Finance

executed a cross-chain Delivery vs Payment transaction.

This is one of the clearest real-world examples of CRE in action.

What Was Being Traded

Asset: Tokenized U.S. Treasuries (OUSG)
Payment: Bank deposit on Kinexys

Where each part lived:

Ondo Chain → Asset layer

Kinexys → Bank payment layer

CRE → Coordination + execution layer

Step-by-Step: How the Transaction Happened

Step 1: The Intent
A participant wants to buy tokenized U.S. Treasuries (OUSG).

But:

The asset is on a blockchain
The money is in a bank

Step 2: The Risk
Without coordination:

Send money first → risk losing funds

Receive asset first → risk not getting paid

In the absence of atomic settlement, there are many hidden but critical risks that may affect the transaction. When one side of a transaction is executed before the other, a party may have fulfilled their side of the transaction but may not receive anything in return. This is referred to as principal risk. Even if both parties are willing to settle, there may be timing risks due to changes in market conditions or system and participant behavior.

Step 3: CRE Coordinates the Transaction
Instead of trusting either side, both systems are connected through Chainlink Runtime Environment (CRE)

Step 4: Conditional Logic Is Enforced
CRE defines the rules:

IF payment succeeds → release asset

IF asset transfer succeeds → finalize payment

ELSE → abort everything

The transaction reverts if any of the conditions fail. This is the beauty of atomic transactions.

Step 5: Parallel Execution
Both systems are triggered simultaneously:

On Ondo Chain:

Prepare transfer of OUSG tokens

On Kinexys:

Prepare transfer of bank deposit

Step 6: Verification and Consensus
CRE nodes:

Monitor both sides
Verify execution results
Reach consensus

Step 7: Atomic Settlement

Only when both sides are confirmed:

OUSG tokens → transferred

USD deposit → transferred

If anything fails:

Everything is rolled back

This is more than just a successful transaction, it introduces a new financial primitive:

Cross-System Atomicity
DvP is no longer limited to a single ledger.
Trust-Minimized settlement as trust would only be on protocol.
No need to trust:
- The counterparty
- The bank
- The blockchain
Real-World Asset enablement as Tokenized assets can now settle against:
- Bank deposits
- Stablecoins
- Future CBDCs

For years, blockchain technology has claimed the promise of "Faster, cheaper, trustless settlement." However, until the problem of cross-system DvP is resolved, the promise is incomplete. Now, with the introduction of CRE, the settlement is not only happening on a particular blockchain but across the entire financial system.

CRE: The Missing Coordination Layer Between Traditional Banking and Blockchain

obiwale ayomide — Thu, 05 Mar 2026 00:45:03 +0000

For years, traditional banking and blockchain have operated in parallel universes.

Traditional banking runs on structured messaging systems using ISO 20022.
Blockchain runs on smart contracts using decentralized consensus.
Both move money.
Both need trust.
But neither talks to the other.

CRE (Chainlink Runtime Environment) changes this balance of power.

CRE is not a blockchain.
It is not a bank.
It is a coordination layer — a programmable execution environment powered by decentralized oracle networks that enables secure communication between off-chain financial systems and on-chain smart contracts.

CRE doesn’t replace banking.
CRE doesn’t replace blockchain.
CRE makes it possible for the two to coordinate with each other.

The Real Problem: Coordination, Not Technology

Traditional finance is a workflow-based business.

Every single financial transaction in a bank, from a wire transfer to a securities settlement, is a process that follows a specific operational flow:

Instruction received
Compliance check
Message formatted (ISO 20022)
Routed to counterparties
Ledger updated
Audit trail created

Blockchain is an event-based system.

Smart contract executes
Token is transferred
Event is emitted

However, that event does not automatically trigger a set of compliance checks in a bank.
The event does not automatically generate an ISO 20022 message.
The event does not automatically update an institutional ledger.

In traditional systems, bridging these two systems together required:

Middleware servers
Reconciliation
Batch processing
Fragile APIs
Centralized relayers

CRE brings something new to the table: workflows.

Let's consider the example of an international wire transfer.

From the customer's perspective:
We enter the details, hit send, and the funds arrive.

Behind the scenes:

The bank authenticates the user's identity.

The transaction is checked for sanctions.

An ISO 20022 message is created.

The correspondent banks work together to settle the transaction.

The ledgers are updated.

The confirmation messages are sent back.

The audit trails are stored.

This is not a single operation.
This is a whole workflow, happening across different systems.

Let's consider replacing one of the banks in the entire workflow with a blockchain network.

Without CRE:

The blockchain can't interpret the ISO 20022 messages.

The bank can't interpret the smart contract events.

We need to implement a custom backend to translate between the two systems.

With CRE:

A banking message can trigger an on-chain event.

An on-chain event can trigger the automatic generation of an ISO 20022 message.

Compliance can be integrated into the workflow.

Reporting can happen in real-time.

The user experience remains the same.
But in the background, the blockchain has been integrated into the same workflow.

Why Major Banks Are Exploring This

Institutions like JPMorgan (through Kinexys), UBS, SWIFT collaborators, and others are not experimenting with blockchain out of curiosity.

They have strategic reasons.

Efficiency & Cost Reduction

Traditional cross-border settlements are slow and layered with intermediaries.

Blockchain offers:

Near-instant settlement
Reduced counterparty risk
Automated reconciliation

CRE enhances this by coordinating blockchain settlement with traditional reporting systems, reducing operational overhead.

Real-Time Reconciliation

Today, banking systems heavily utilize batch processing and reconciliation systems.

Blockchain technology allows for deterministic state changes with timestamps.

CRE facilitates this by ensuring:
Integration with existing ledger systems
Generation of structured financial messages
Record maintenance

This removes friction from the back-end systems.

ISO 20022 Integration

ISO 20022 is the global financial messaging standard.

It’s the language of modern banking.

But blockchains don’t natively support this language.

CRE can:

Translate ISO 20022 instructions into programmable blockchain actions.
Generate ISO 20022 compliant outputs from on-chain state changes.

That’s important.
It means banks don’t have to abandon their infrastructure to benefit from blockchain.

A More Detailed Analogy: The Bank Operations Floor

Imagine the operations floor of a large bank.

There are:

Risk teams
Compliance teams
Settlement systems
Messaging systems
Ledger systems
Audit systems

When a major transaction happens, all these units coordinate.

Now imagine a digital “conductor” that:

Receives a financial instruction
Automatically calls compliance checks
Formats standardized financial messages
Routes instructions to the right systems
Updates ledgers
Logs immutable records
Confirms completion

CRE acts like that conductor — but across both banking systems and blockchain networks.

It ensures:

On-chain actions integrate with traditional workflows.
Traditional banking messages can trigger programmable execution.
Everything remains auditable and structured.

The Deeper Shift: From Transactions to Coordinated Infrastructure

The most significant change is this:

Blockchains have been transactional.
Banking has been procedural.
CRE makes blockchains procedural.

Instead of smart contract events, you get institutional workflows.

Instead of:
“Something happened on chain, now go reconcile it manually.”

You get:
“Something happened, and the entire institutional workflow happened automatically.”

That is synergy.

The Bigger Vision

This is not about replacing SWIFT.
This is not about replacing banks.
This is not about replacing traditional finance.

This is about integration.

CRE enables:

Structured financial messaging (ISO 20022)
Blockchain programmability
Real-time settlement
Compliance-aware execution
Cross-system coordination

This is about bridging decentralized execution and institutional operational standards.

Invisible complexity.
Visible reliability.

This is why the biggest financial institutions are taking a look.
This is why the conversation around blockchain is shifting from speculation to infrastructure.

Reading Contract State at a Past Block Using Wagmi

obiwale ayomide — Thu, 08 Jan 2026 16:56:35 +0000

There was a moment when I needed to answer a deceptively simple question:

“What was the price of this asset then, not now?”
Not five minutes ago.
Not the current block.
But at a very specific point in the past.

I was working on a feature that needed historical pricing for an asset. Not off-chain charts, not an indexer snapshot, but the actual on-chain value that existed at a given time. Since the asset used Chainlink price feeds, I assumed this would be straightforward.

It wasn’t.

At first, I kept getting the current price no matter what I tried. That’s when I realized something important: most examples show you how to read contract state, but very few show you how to read contract state at a specific block.

That’s where Wagmi quietly shines.

The Core Idea

Ethereum (and EVM chains in general) allow you to query contract state as it existed at any historical block. If a contract method is view or pure, you can read it at a past block without any special indexing infrastructure.

Wagmi exposes this directly through blockNumber.

So instead of asking:
“What does the contract return now?”

You ask:
“What did the contract return at block X?”

For price feeds, this is gold.

The Scenario: Chainlink Price at a Past Time

Chainlink price feeds expose methods like:
latestRoundData()
getRoundData(roundId)

If you already know the round ID, you can query it directly. But sometimes you don’t. Sometimes all you know is the time.

A reliable approach is:

Convert the timestamp you care about into a block number
Read the price feed contract at that block
Let’s focus on step 2 using Wagmi.
Reading a Contract Method at a Specific Block
Wagmi’s readContract (or useReadContract) accepts a blockNumber parameter.

import { readContract } from '@wagmi/core'
import { parseAbi } from 'viem'

const aggregatorAbi = parseAbi([
  'function latestRoundData() view returns (uint80,int256,uint256,uint256,uint80)'
])

const priceFeedAddress = '0x...'

const blockNumber = 18_500_000n

const data = await readContract({
  address: priceFeedAddress,
  abi: aggregatorAbi,
  functionName: 'latestRoundData',
  blockNumber,
})

What happens here is subtle but powerful.

Wagmi asks the RPC node:

“Pretend the chain is at block 18,500,000. What does this function return?”

The result is exactly what the Chainlink contract would have returned at that block, not today.

Why This Works

Ethereum nodes store historical state. When you specify a blockNumber, the node executes the call against that historical snapshot.

No subgraph.
No off-chain cache.
No guesswork.

Just deterministic blockchain state.

Mapping Time to Block

You usually don’t know the block number upfront. You know a timestamp.

Typical approaches:

Binary search blocks by timestamp using eth_getBlockByNumber

Use a helper API once, then cache the mapping

Use an archive node for accuracy

Once you have the block number, Wagmi does the rest.

Frontend Example with React

If you’re using Wagmi hooks in a React app:

import { useReadContract } from 'wagmi'

const { data } = useReadContract({
  address: priceFeedAddress,
  abi: aggregatorAbi,
  functionName: 'latestRoundData',
  blockNumber: 18_500_000n,
})

This is especially useful for:

Historical charts
Auditing old positions
Liquidation simulations
“What-if” analytics
Dispute resolution in DeFi

Important Caveats

RPC support matters
You need an RPC that supports historical reads. Some free providers prune old state.

Performance
Historical reads are slightly heavier. Cache results when possible.

Final Thoughts
Wagmi doesn’t make a big deal out of this feature, but once you realize you can read contract state at any point in time, a lot of problems suddenly become simpler.