On This Page
Consider an illustrative browser task with one hundred steps. Suppose each step succeeds 99% of the time, independently of the others. The chance that every step works is 0.99^100, or about 36.6%.
Ninety-nine percent sounds excellent. Thirty-six percent does not.
The source discussion of transactional browser work uses this calculation to make a narrow point: the customer gets value when the task finishes, while cost and failure risk accumulate at every step. It is arithmetic under an assumption, not a published success rate for any browser agent or Tajo sync. Real errors can depend on one another. One expired login can break several later actions at once.
The useful question is therefore not “How accurate was the model’s last click?” It is “Did the user’s requested state appear?”
The transaction is the unit that matters
Imagine an agent opening an insurance portal, finding a document, downloading it and confirming that it belongs to the correct account. It can navigate 99 screens correctly and still download the wrong file on screen 100. A call log full of successful clicks does not repair the result.
The same distinction applies to an integration. An agent can discover an API, propose a field mapping and save a draft. None of those actions means a destination contact now has the intended consent state. The work is complete only when the approved operation has run and its relevant postcondition has been checked.
This is a difference between activity and completion. Activity is easy to count. Completion needs a definition.
For a file download, the definition might be an artifact whose account number matches the request. For a contact sync, it might be a destination record with the correct identifier, fields and permitted messaging status. The check must inspect the thing the user cared about. A green response from the preceding call is evidence that a call returned. It may not be evidence that the destination changed as intended.
Tajo’s guide to connecting business tools starts with the workflow and the source of truth for each data object. Those choices give the final check its meaning. If two systems both claim to own a field, even a perfectly executed write may produce the wrong long-term state.
The cost of another decision
Under the same hypothetical 99% assumption, ten independent decisions yield about 90.4% full-chain success. Fifty yield about 60.5%. One hundred yield about 36.6%.
Whole-chain success probability (%)
Number of independent steps
- Assumed 99% success per step
Read the calculated values
| Steps | Whole-chain success (%) |
|---|---|
| 0 | 100.0 |
| 10 | 90.4 |
| 25 | 77.8 |
| 50 | 60.5 |
| 75 | 47.1 |
| 100 | 36.6 |
The curve is steep because multiplication has no sympathy for a good average. Each additional decision must earn its place.
That does not mean every API call should be collapsed into one giant operation. Some calls are deterministic: fetching a page with a known cursor, comparing an identifier, or writing a field according to an approved mapping. A model does not need to decide those again for every record. Other calls involve genuine ambiguity: a new vendor field, a changed error message, or a request whose owner is unclear. Those may need judgment.
The practical split is to let judgment design or repair a rule, then let ordinary code apply the stable rule. Reverse ETL is a useful example of repeated data movement: the pipeline, not a conversation, should perform each routine row operation. An agent can still help decide what the pipeline ought to do.
This is a boundary, not a slogan. If a vendor changes the meaning of a field, a deterministic rule can repeat the wrong action perfectly. The system needs a way to detect that its assumptions changed and return the case to review.
Why one big tool is not the answer
A fair objection is: “If long chains fail, put the entire task behind one tool call.” That helps when the tool is a well-defined transaction with a checkable result. It fails when the tool merely hides a long, uncertain process.
Suppose syncCustomer() returns success: true after sending an update. If the destination processes updates later, the call cannot yet prove the final contact state. The tool reduced visible steps. It did not reduce uncertainty.
A better interface exposes the state that matters: accepted, applied, checked, or failed. Those words should correspond to evidence. An accepted write may be enough for a low-consequence preview. A campaign audience or consent change deserves a destination check before anyone calls it complete.
In this proposed Tajo view, an accepted request and an applied update are separate from a verified destination state. The final check remains pending. That distinction gives the next action a purpose: inspect what the destination stored. Counting one more successful tool call would leave the original question unanswered.
A finished write still needs evidence
Did the customer sync finish?
Write applied. Verification pending.
The destination state has not been checked yet.
Sync activity
- Request accepted
- Update applied
- Destination check pending
Example run · 14:32 UTC
What we know
- Provider response
- Accepted
- Write result
- Applied
- Destination readback
- Pending
A successful call does not prove the final state.
Proposed layout informed by Tajo's activity feed. This illustration adds a verification state; it does not claim that destination readback is already implemented.
This also changes what to measure. Record the number of attempts if it helps diagnose cost. Record intermediate errors if they point to a broken step. But judge the workflow by verified completed transactions, with the verification method written beside the number. A team that reports “99% of calls succeeded” has not answered whether customers got their work done.
The MCP server explainer shows how tools let an assistant call another system. Tool access is only the opening move. The contract is the state left behind.
A hundred good clicks can still leave nothing. Count the result.
Frequently Asked Questions
Why does a long workflow fail when its steps are usually correct?
If each step succeeds independently with probability p, an n-step chain succeeds with probability p to the power n. At an assumed 99% per step, a hundred-step chain completes about 36.6% of the time. Actual failures may be correlated, so the calculation is an illustration rather than a measured agent rate.
Does reducing the number of tool calls guarantee reliability?
No. Fewer calls help only when the combined operation still exposes the right checks and recovery points. A single opaque call can hide a failed write as easily as a long chain can lose its place.
What should a team measure for an agent workflow?
Measure verified completion of the user's transaction, not only successful model calls. Define the artifact or destination state that proves the job finished, then record how often it appears after the whole workflow.