Why Fetch.ai autonomous agents lose connection with the blockchain
Fetch.ai autonomous agents make decisions on their side: they maintain a state model, calculate trigger conditions, and sign the operation themselves, without a human in the loop.
The network, meanwhile, lives by its own rules — finality does not occur instantly, some events are rolled back, and the order of operations is set by consensus, not by the agent.
As long as these two worldviews coincide, AI agent integration looks workable; state divergence shows up later and not where it is expected.
A typical failure starts with data oracles: a state snapshot reaches the agent with a delay, and inside the agent it is also cached for several cycles. The decision is made on outdated data — price, available volume, or access right by the time of execution is already different.
The agent acts formally correctly, but on an incorrect picture, and this is not visible from its logs.
The second half of the problem is repeated operations. Without waiting for confirmation, the agent does not know whether the first attempt arrived and sends a second one.
The registry receives two identical records, positions diverge from the accounting ones, and the investigation takes more time than the transaction itself. If the operation is irreversible, it cannot be rolled back on-chain — only compensated.
The root is one: the logic of an autonomous agent lives separately from the network state, and the boundary between them is not controlled in any way.
We break down how this is closed — by reconciling state before signing, idempotency keys, and a journal of the agent's intentions.
What agent integration gives: speed, failures, manual operations
An agent in Fetch.ai is a service that independently monitors events on-chain and off-chain, applies rules, and triggers the next action.
The uAgents set forms an execution layer between your systems: it does not wait for an operator to open an interface, but reacts to a state change.
The effect here is measured across four dimensions — operation time, eliminated class of failures, share of manual reconciliations, and audit completeness.
Operation time is reduced because there is no human between the event and execution. The agent checks the condition, collects confirmations, and sends the transaction in one pass — the median time from event to execution drops from hours to seconds.
The difference is visible not in a demo, but in the flow: the more operations per unit of time, the more the old and new schemes diverge.
A separate class of failures — repeated execution and state divergence — is removed at the level of agent logic. Idempotent handlers, deduplication by operation ID, and retry with a limited number of attempts eliminate double charges and stuck orders.
Errors that previously surfaced a day later during reconciliation are cut off at the moment of processing.
The share of manual reconciliations falls because there is nothing left to reconcile: the agent's state and the system's state converge on the same event.
The operator gets involved only in exceptions that the agent has flagged as disputed — the investigation queue shrinks by several times, not by percentages.
Audit is built from the agent's decision journal: input data, the rule that triggered, the result, and the executor's signature. With such a record, an action is reproduced step by step, so a dispute is resolved along one chain, not across logs in different systems.
It is the completeness of this journal that determines whether operations can be handed to the agent without manual confirmation.
Fetch.ai integration options: cloud, hybrid, own environment
Agent logic and its private keys are two different entities, and they can be placed in different ways. The key question of an integration option is: where the keys physically reside and who initiates the transaction signature. This determines both the key storage scheme and whether your data enters an external perimeter.
| Option | When it fits | Limitations |
|---|---|---|
| Cloud infrastructure | Fast agent launch, isolation is not critical | Keys outside your perimeter, provider dependency, separate access audit required |
| Hybrid scheme | Control over keys needed with external compute load | More complex routing, state desynchronization between parts |
| Closed environment | Regulatory requirements, sensitive data | External services unavailable, all registry maintenance on your side |
How this works in practice
In cloud infrastructure, uAgents are deployed in containers, scale with load, and immediately see external services.
The hybrid scheme takes the compromise: the compute part lives outside, while signing and key storage remain on your node — the agent works with external data without giving up control over assets.
A closed environment is chosen when external connections are not allowed: exchange happens inside the perimeter, entry points are closed, and communication with external registries goes through controlled gateways.
The price for this is manual synchronization and more maintenance. Describe the task — we will come back with an estimate and a plan for your perimeter.
Work sequence: from scenario audit to environment handover
The work sequence is the same for both the first launch and the production environment: first we record what decisions the agent makes and on what data, then we design the scheme, and only after that do we move to implementation.
This order removes the main risk — when the integration is already built, but the scenario does not converge on real data and part of the work has to be redone.
- Scenario and data audit — we break down the tasks that Fetch.ai agents cover, describe sources, trigger conditions, and how the decision is made now.
- Interaction scheme design — who exchanges messages with whom, what happens when a source is unavailable, where a manual confirmation step is needed.
- Agent configuration — processing logic, connection of data sources, error-handling rules, and rate limits for calls to external services.
- Test run — we run scenarios on historical data and in a closed environment, and compare agent responses with expected ones.
- Load testing — peak requests, message queue, response time, and failure correctness.
- Solution handover and team training — we hand over the scheme, configurations, journals, and operating regulations, and go through disputed cases with your team.
Each stage is closed with a verifiable artifact: a scenario map, a scheme, test data sets, a load report, documentation. We agree on interim results as we go — you see progress through the stages, not a final demonstration.
What remains with you: schemes, policies, regulations, documentation
Agent integration is not only working code on-chain. In six months, no one will remember why the agent has exactly these call limits, how it gets access to the wallet, and what to do if a node fails.
That is why we hand over the project so that it can be developed and operated without us: any artifact opens, reads, and is applied in practice. Below is a typical set based on the results of work with Fetch.ai and uAgents.
- Interaction schemes — which agents exchange messages, on which topics, who initiates the request, where external services and failure points are.
- Agent configurations — launch parameters, limits, binding to networks, environment variables, rules for updating addresses and keys.
- Data flow scheme — from the incoming event to the on-chain record: what is stored where, what is logged, what goes to external systems.
- Access and role policies — who signs operations, who changes configuration, who reads journals; the procedure for issuing and revoking keys.
- Operating regulations — scheduled agent updates, rollback to a previous version, response to a crash and to balance divergence.
- Observability — a set of metrics, threshold values, where alerts arrive, and who responds to them first.
- Project documentation — architecture description, adopted decisions and their reasons, known limitations of the current branch.
- Knowledge transfer to the team — a walkthrough of the stand with your engineers, answers to questions, joint revision of the first update.
Case study: data marketplace reduced manual reconciliations threefold
A data marketplace connects providers of data sets and buyers: settlement takes place on-chain, and access rights are issued on the service side.
The team performed reconciliation between the transaction journal and access records manually — an analyst matched transaction IDs, terms, and deadlines.
This took up to a third of support's working time, and discrepancies surfaced days later: the buyer was already working with the data set, although payment confirmation had not gone through.
What was changed in the agent logic
We assembled an agent layer on uAgents from Fetch.ai: a provider agent publishes deal terms, a buyer agent verifies them and initiates settlement, and an auditor agent listens to events and collects evidence for each operation.
Reconciliation rules were moved into declarative conditions — access, deadlines, limits, the procedure for resolving discrepancies — and we stopped editing code for every new requirement.
Handlers were made idempotent with a key based on the deal ID: repeated event delivery does not create a duplicate or corrupt the journal.
After launch, the share of operations going to manual reconciliation fell from 34% to 11%, event reaction time — from 40–90 minutes to single-digit seconds, and the number of disputed operations decreased fourfold.
Manual review remained only where external sources diverge, and that is now an exception, not daily work. Agent logic delivered not "AI magic" but a predictable environment: every action leaves a trace, and any discrepancy is reproduced from the journal.
How does an autonomous agent differ from a regular on-chain script?
An on-chain script is a pre-described sequence: check a condition, call a contract method, record the result. The decision is made by the code author, and execution follows strictly the built-in branch.
An autonomous agent receives a goal and rules, and chooses the specific action itself at each step — what to call, when to wait, when to abandon a deal.
The difference between the approaches is most visible in an unforeseen situation. A script, having received the wrong response or hit a limit, either crashes or enters a wait loop, the transaction is rolled back — and the system stands still until a human intervenes.
The agent sees that the route did not work and rebuilds the plan: takes an alternative data source, moves the action to the next step, reduces the volume to an acceptable level.
The boundaries of autonomy do not appear by themselves — they are set in the rules: what the agent reads, which contracts it calls, which actions must go for confirmation.
The narrower these boundaries, the closer the behavior is to a script: more predictable and reliable, but less useful where flexibility is needed.
The risk class also changes. For a script it is binary: it worked or it did not. For an agent, a third state appears — an action that is formally permissible, but not the one intended.
That is why the environment includes hard limits on actions, a decision journal with justification, and a stop point that shuts down the agent without losing state.
In Fetch.ai, an agent is a service with its own logic and address that exchanges messages with other agents.
The practical takeaway is simple: a script automates a known scenario, while an agent takes on one that cannot be fully described in advance — and this is built into the design from day one.
Technical concerns: keys, load, security, rollback
Before starting Fetch.ai agent integration, customers ask five questions: keys, source failure, load, change rollback, and product compatibility. Below are short answers that make it convenient to check the solution against requirements.
Where are signing keys stored?
The agent key resides in a secrets manager and is issued for the duration of an operation — it does not get into code or the repository. Rotation is scheduled, and permissions are separated: the agent signs only its own transactions.
What happens if a source fails?
The agent does not send a transaction based on outdated data: the request is retried with an increasing pause, and the event goes to the queue. If the source is silent longer than the threshold, a circuit breaker trips and the on-call person is notified.
How will this affect load?
The agent reacts only to confirmed changes, so network calls are a fraction of the total event flow. The queue is processed by workers with limited concurrency — a peak does not turn into an avalanche of requests.
Can changes be rolled back?
Yes, with idempotent design. The contract keeps an operation journal, a retry with the same ID does not create a duplicate, and disputed operations are reviewed manually after the agent is stopped.
Is it compatible with the current product?
The agent connects as a separate service and works through existing interfaces. Scenarios are first tested in a shadow environment and turned on gradually — there is no need to rewrite the product.
Let's discuss the task and come back with an estimate and work plan
A project estimate becomes truthful only from your picture of the task, not from general words. For the first step, a description is enough: which scenarios the agents cover, which services and data they work with, who owns the keys, and where the results of their actions go.
In the first conversation, we clarify the boundaries of automation and the operating modes of agents on Fetch.ai: what the agent does itself, what a human confirms, what limits we set on actions, and how we roll back an erroneous trigger. After that, we fix the work plan and come back with an estimate.
What we will come back with after discussing the task:
- a scenario map: which agents, which tasks, where automation begins and ends;
- an integration scheme with your services, wallets, and external data sources;
- an access model: who holds the keys, what limits and confirmations are set on agent actions;
- a set of stages with acceptance points — what is considered complete at each step;
- implementation timelines by stage and the procedure for bringing agents into operating mode;
- a list of risks and ways to remove them, including conditions for rollback to the previous state.
The first step is an email or a short call describing the task: that is enough to see the scope of work. We send the estimate, work plan, and implementation timelines by stage in a single document so they can be checked against your priorities.