From 5 Hours to 13 Seconds: a Prospecting Agent with Guardrails

For years, prospecting one account took me an afternoon. On October 12, 2026, I watched a process run the full preparation cycle in thirteen seconds, spend two and a half cents, and stop on its own before the only step that matters: sending. This is what we measured, what we built so that speed would be tolerable, and what I think after seeing it.

Short answer. Transgenia connected its prospecting agent, Aitana, to a local worker that runs on Claude's Messages API and a scoped MCP connector to the ERP. In two real cycles the worker read the database, decided, created an empty mass-mailing draft, read it back and settled its spend: 13 and 15 seconds per cycle, USD 0.045 in total, zero emails sent. The month before, the same sales channel had gone 48 days without a single send because every step depended on a person. Speed is not the news. The news is that it was tolerable only because sending is out of the agent's reach, the budget is reserved before thinking and every claim has a read-back. We call that respect for artificial intelligence.

Diagram 1. The manual prospecting process in seven steps, from choosing the account to planning the next touches, with an estimate of minutes per step that adds up to three to five hours. — Diagram 1. The prospecting afternoon as the author lived it before the pilot. The minutes are a personal estimate, not telemetry; the three to five hour total per prospect is the baseline figure in this article.

The five-hour afternoon: how a person prospected

I carry most of Transgenia's sales. Before the pilot, prospecting a new account was a full afternoon. Choose the company and understand what it does. Find the emails and the decision maker, who is almost never published. Make a preliminary call to confirm the person exists and the topic concerns them. Draft the email. Curate it: cut adjectives, verify every figure, add the right signature and the two attachments our policy requires. Send it and log it. And plan the next touches, because an email without follow-up is an email thrown away.

As a rough guess, three to five hours per prospect. I use that phrase deliberately: it is a personal estimate, not telemetry, and that is how the rest of this text treats it. Nobody timed those afternoons with a stopwatch. What we did measure, in detail, was what came next.

The problem with that process was not its quality. It was that it only happened when I had a free afternoon.

What our telemetry said in September

We have had a prospecting agent since mid-2026. It is called Valentina in the code and Aitana in the commercial signature. We already told on this blog how we designed its demo motion and its hard rules. What we had not told is what happened when operations depended on a person starting every step.

Our weekly review log, which a management agent writes every Saturday from the system's records, marked the sales channel red in weeks 35 and 36. The data is ours and we quote it as it was written:

Zero outbound sends during the whole week, two weeks in a row.
The last email went out on July 21. By September 7 the silence had reached 48 days.
A sweep of 92 curated leads, with verified phone, email and website, had sat inactive for 24 days.
The Saturday digest had not been generated in ten weeks. The Monday digest had been blocked for six weeks by a condition in an automation flow.
The scoreboard for the half-year goal showed 0 % progress, with 38.5 % of the time consumed.

Diagram 2. Timeline of the sales channel from July to September 2026: last wave on July 21, a sweep of 92 leads on August 14 left inactive, weekly reviews in red on August 29 and September 7, and the Saturday digest not run for ten weeks. — Diagram 2. What our own weekly log said before the pilot. The agent existed and the templates were ready; what was missing was someone to start every step. Outbound silence reached 48 days.

That was the state of the art of our own operation. The templates existed. The sender with suppression and a daily cap existed. The lists existed. The agent existed. What did not exist was a process that would start, do its work and stop without someone accompanying it from beginning to end. And since that someone was me, and I was selling, the channel stood still.

It should be said plainly: an agent that needs a person for every step is not an agent. It is a well-written form.

Why "switching on" the agent was not enough

The natural reaction to that diagnosis is to give the agent permission to act alone. We refused, and the reason lies in the runtime's technical history.

Valentina went through seven versions before touching a real mailbox. The first decision was about platform: our own implementation on the Messages API, because in the validation at the time managed agents were not available for our organization. Then came a runner that only produced drafts from synthetic data. Then a ledger with idempotency by message identifier and a global limit of five attempts per person. Then handling of the email provider's deferrals and terminal reconciliation. Then fail-closed: any ambiguous code is treated as failure and never retried. Then a durable SQLite ledger that survives restarts and two concurrent processes. And finally, the health read of an IMAP mailbox, first tested offline with 219 automated tests and then executed once, live.

Diagram 3. Evolution map of the Valentina runtime: platform decision, drafts-only mode, ledger and attempts, deferrals, fail-closed, durable ledger, mailbox health prepared offline and real health verified on October 12. — Diagram 3. Seven versions before a single email. Each step closed with tests that never touched the network; the only real mailbox read was done read-only and recorded with its hash.

That single live read, on October 12 at 00:13 Mexico City time, ran over TLS 1.3 with a verified certificate, opened the folder with the EXAMINE command, which in the IMAP protocol means read-only mode, and logged out. Four commands recorded, zero mutations, evidence stored with its hash. It did not read a single message.

I tell all of this because it explains the standard we later demanded of the worker. If looking at a mailbox without touching it required 219 tests and an authorization with an exact phrase, writing to the ERP was not going to require less.

The platform decision: a local, finite process

On October 10 we revalidated the architecture against Anthropic's current documentation. The conclusion was less ideological than it sounds.

Claude's managed agents, the ones that run in the cloud with persistent sessions, connect their tools through MCP servers with a remote URL and per-session authentication through a credential vault. That is the right design for published infrastructure. Our tools are not published: the connector to the ERP runs in a container inside a desktop computer, with no exposed ports. A remote connection to localhost does not exist. Until we have a remote gate that is persistent and authenticated, that route was not a path.

Desktop extensions, for their part, are a good surface for a person to work with the agent, but they are not a synchronization bridge, and we were not going to hand them sending credentials.

Diagram 4. Comparison of two routes: managed agents in the cloud, which require MCP connections with a remote URL and per-session authentication and therefore cannot reach local services, versus a local worker that uses the Messages API and the MCP server on the same machine. — Diagram 4. Why we chose a local, finite process instead of a managed agent. It was not an objection to the product: our services live on a desktop computer, and a remote connection to localhost does not exist.

We chose the boring option: a local Node process, with no new dependencies, that starts when a person clicks, calls the Messages API with a fixed model, uses the local MCP connector and exits. It is not a permanent service. It is not installed as a scheduled task. It opens no ports. If the computer is off, nothing happens, and that too is documented as a limit.

A cycle that ends on its own

The cycle's contract was written before the code, and we drew it before implementing it. A person starts. The worker verifies the ERP's identity, the authorized credential source and the budget. It reviews scoring, touch history, unsubscribes and replies. If evidence is missing or there is no eligible audience, it ends in HOLD with a report, and HOLD never retries on its own. If there is an audience, it freezes an immutable batch and waits for a human sign-off, with no waiting loop: the process simply exits and leaves the batch ready. The send, when it happens, goes out exclusively through the ERP's mass-mailing module, never through an SMTP of the agent's own.

Diagram 5. The agent's operating cycle: preflight, eligibility review, HOLD with a report if evidence is missing, immutable batch, waiting for sign-off without a loop, revalidation and dispatch exclusively through the ERP's email channel, with trace reconciliation at the end. — Diagram 5. The cycle's contract. The only transition that leads to a send goes through an explicit human sign-off and a later revalidation. Everything else ends in HOLD with a report, and HOLD never retries on its own.

On October 12 we ran two real cycles and a third, empty one.

The first was read-only: two inferences, two count calls to the ERP, a report on disk and process exit. Fifteen seconds passed between the budget reservation and its settlement. Calculated spend: USD 0.018.

The second is the one that matters. With explicit authorization for a single write, the worker created a mass-mailing template with no recipients, with a subject line that says in capital letters that it must not be sent, read it back, counted the associated emails and traces, and found zero and zero. Two inferences, one write, 13 seconds between reservation and settlement. Calculated spend: USD 0.026.

Diagram 6. Sequence of the worker's second real cycle: budget reservation, first inference, call to the tool that creates the draft, second inference, independent read-back of the draft and settlement of the spend, with thirteen seconds between reservation and settlement. — Diagram 6. The thirteen seconds, reconstructed from the budget ledger and the per-request usage log. Two inferences, one write, zero recipients and a calculated spend of USD 0.026.

The third launch was the one that reassured me most. We ran it as a daily cycle: the worker looked for new candidates after applying suppressions, the five-touch history and the previous batch's exclusions, found none, and exited without a single inference, without creating templates and at zero cost. A second click the same day returned the previous result with the replay flag set and the ledger hash intact.

Total for the two cycles with inference: USD 0.045 out of an authorized USD 20 pilot.

The guardrails that make the speed tolerable

The part I care about sharing is not the speed. It is the list of things we decided before switching the process on, because those are what make thirteen seconds not thirteen seconds of risk.

The budget is reserved before thinking. Each cycle writes a USD 5 reservation to a durable ledger before the first inference. If the reservation does not fit within the pilot cap, the process does not start. On exit it settles at the consumption calculated from the token usage reported by the API and the model's public rates. If the outcome is uncertain, it keeps the full reservation and blocks the next cycle until a person reconciles. The internal limits are explicit: at most eight model turns, twenty connector calls, 2,048 output tokens, a 120-second timeout and no automatic retries. The model is pinned and there is no silent fallback: if the price or the model changes, someone has to change it by hand.

Diagram 7. The worker's budget model: a five dollar reservation before each cycle, a check against the twenty dollar pilot cap, settlement at the calculated consumption using public rates, and retention of the full reservation if the outcome is uncertain. — Diagram 7. Money is reserved before thinking, not after. If the worker cannot prove how much it spent, the ledger assumes it spent the whole reservation and blocks the next cycle until a person reconciles.

One cycle per day and one process at a time. A local lock prevents two simultaneous cycles. The local date decides whether a cycle already happened; a second launch returns the previous result without spending. A day with no new candidates ends without inference and without empty drafts, because an empty draft created out of routine is also noise in the ERP.

Diagram 8. Repetition guardrails: a local lock prevents two simultaneous cycles; one cycle per local date; a second launch on the same day returns the previous result without spending; and a day with no new candidates ends without inference or drafts. — Diagram 8. What happened on October 12 with the third launch: no new candidates, no inference, no spend and no empty templates. A second click that same day returned the previous result, with the ledger hash intact.

The connector has no send button. The dedicated MCP server exposes six read tools and two draft tools: create and edit only the drafts the cycle itself created, with a cap of ten recipients. There is no tool to send, schedule, delete or modify contacts. It is not a policy written in a document the agent could ignore: it is an absence in the code. Sending is done by a person, from the ERP, after reviewing the batch.

Diagram 9. The connector's two layers of tools: six read tools, plus creating and editing the cycle's own drafts with a recipient cap; and the list of what the connector cannot do: send, schedule, delete or modify contacts. — Diagram 9. The connector has no send button. It is not a policy written in a document: it is an absence in the code. The worker's speed becomes tolerable because the irreversible step is out of its reach.

Every claim has a read-back. The worker does not report "I created the draft". It reads the record back, verifies it is in draft state, counts the associated emails and traces and writes those zeros in the report. We repeat those reads with independent queries before accepting the cycle. An agent's report is a hypothesis until someone checks it.

Commercial rules are code too. At most five touches per person, counted across campaigns and channels. One logical batch per day. Short copy with evidence, no fabricated figures. A lead that is already an opportunity or a customer does not enter cold prospecting. These rules existed in our skills as text; some of them now live in the guard that runs before every write, which fails closed if it cannot verify the history.

What the pilot proved and what it did not

We forced ourselves to make this distinction before writing the article, because it is very easy to confuse technical capability with commercial results.

Diagram 10. Two columns: what the pilot proved, as the technical ability to read, decide, write a draft and stop under budget, versus what it did not prove, such as a new commercial audience, a real send or operation without the computer on. — Diagram 10. The distinction we forced ourselves to make before writing this text. An empty draft created by a machine is proof of technical capability, not an eligible commercial batch.

It proved that an autonomous process can read the ERP with scoped tools, decide, write its own draft, read its write back, reserve and settle budget, and stop on its own when there is no work. All of it with evidence: manifests, ledger, read-backs and automated tests, 219 for the runtime and 13 for the worker.

It did not prove a new, approved commercial audience: the database offered no eligible candidates that day without relaxing the criteria, and we did not relax them. It did not prove a real send to a prospect; there was none. It did not prove operating with the computer off or on a remote server. It did not prove receiving or classifying replies; the mailbox health read is not ingestion. And it did not prove that the model key has a global spending limit: the ledger limits this worker, not other programs using the same key.

An empty draft created by a machine is proof of technical capability. It is not an eligible batch, and we do not present it as one.

The honest comparison: hours against seconds

I want to be careful with the figure in the title, because it is the one that will be repeated most.

The three to five hours are a personal estimate per prospect, end to end, including the call and the planning of the next touches. The 13 and 15 seconds are telemetry per cycle, reconstructed from the budget ledger and the per-request usage log. A cycle does not include the preliminary call or the decision to send, and in these tests it did not include a real audience either. We are not comparing like with like, and we would rather say so than have an attentive reader discover it.

Diagram 11. Honest comparison: human work per touch, three to five hours, versus the machine cycle, thirteen to fifteen seconds; in between, the human decision to send, deliberately kept as the only bottleneck. — Diagram 11. We are not comparing like with like, and we say so. The hours are a personal estimate per prospect; the seconds are telemetry per cycle. What sits between them, the decision to send, is the bottleneck we want to keep.

What does change, and changes for real, is where the bottleneck sits. Before, the bottleneck was my afternoon. Now the bottleneck is a decision: review a frozen batch and give a sign-off. That decision takes minutes, not hours, and it is the only one we want to keep, because it is the only irreversible one.

When I saw the report of the second cycle I felt something I did not expect to feel in front of a text file. I felt fear. Not because the process had done something wrong, but because it did something right faster than I could observe it. That feeling is what gives rise to the last section.

Where Transgenia stands

This article is not neutral and it is worth saying so. Our position, so you can contrast it with any other provider's:

Artificial intelligence deserves respect. Not fear and not worship: respect in the operational sense, the kind owed to any system able to act faster than we can supervise. The pilot's results earn that respect, and the mature answer to the fright they cause is engineering, not enthusiasm.
Limits are written before switching on, not after the first incident. Reserved budget, one cycle per day, a lock, a recipient cap and the absence of a send tool are prior decisions. A guardrail added after a mistake has already cost that mistake.
An agent that needs a person at every step is not an agent. We learned that with 48 days of silence. The right autonomy does everything reversible on its own and stops at the irreversible.
The irreversible is decided by a person with a name. At Transgenia the sign-off for every batch is signed by the managing director. Not a committee, not a probability rule: someone who looks at the batch and answers for it.
An agent's report is a hypothesis. Every claim by the worker is checked against an independent read before it is accepted. If we cannot verify it, we mark it as not proven, as we did above.
Speed without evidence is worth nothing. Thirteen seconds is an interesting figure only because the ledger, the manifests and the read-backs exist. Without them, it would be thirteen seconds of faith.

Diagram 12. Model of operational respect for artificial intelligence in five steps: from the initial fright to limits written before switching on, evidence for every claim, delegation with human sign-off and earned trust that allows permissions to grow on evidence. — Diagram 12. Our thesis in one drawing. Respecting artificial intelligence is neither fearing it nor worshipping it: it is treating it like any system that acts faster than we can supervise, with prior limits, evidence and a person at the irreversible step.

Sources

Technical facts about products and protocols rest on public sources. The pilot and sales-channel figures are Transgenia's: they come from our internal audit log of October 10 to 12, 2026, and from our weekly reviews of August and September, and are marked as such.

Anthropic, Messages API reference: the API the local worker uses for its inferences, with a per-request output token limit.
Anthropic, Claude Sonnet 5.5: the model pinned in the worker.
Anthropic, public model pricing: USD 2 per million input tokens and USD 10 per million output tokens for Sonnet 5.5, the rates the ledger uses to calculate spend.
Anthropic, Managed Agents and its MCP connector: managed agents connect tools through MCP servers with a remote URL and per-session authentication; the reason behind the platform decision.
Model Context Protocol: the open standard behind the connector to the ERP.
RFC 9051, IMAP4rev2: the EXAMINE command opens a mailbox in read-only mode, as in the runtime's health read.
RFC 8446, TLS 1.3: the protocol that read ran over.
SQLite, atomic transactions: the engine behind the runtime's durable ledger; its transactions are atomic and durable even through a power loss.
Transgenia, Governed AI sales agents for B2B in Mexico: the demo motion and hard rules this pilot inherits.
Transgenia, How we run with governed AI agents: the draft-first and sign-off model.
Transgenia, pilot telemetry (cycles of October 12, 2026, budget ledger, manifests and read-backs) and weekly sales-channel reviews (weeks 35 and 36 of 2026): internal company records, cited without record identifiers or contact data.

Frequently asked questions

Does the agent send emails on its own?

No. The connector the worker uses has no tool to send, schedule or delete. It can read the ERP and create or edit its own drafts with a cap of ten recipients. Sending is done by a person from the ERP's mass-mailing module, after reviewing the batch and giving an explicit sign-off.

What exactly does "13 seconds" mean?

It is the time between the budget reservation and its settlement in the worker's second real cycle, reconstructed from the ledger and the per-request usage log. It includes two inferences, one draft write and the verification reads. It does not include the preliminary call, the human review or the decision to send.

Where do the three to five hours come from?

It is the author's personal estimate of the full manual prospecting process for one account: research, finding emails, calling, drafting, curating, sending and planning the next touches. It is not telemetry and the article says so every time it uses it.

How much did the pilot cost?

The two cycles with inference added up to USD 0.045, calculated from the token usage reported by the API and Sonnet 5.5's public rates, out of an authorized USD 20 pilot with a USD 5 cap per cycle. The third cycle, with no new candidates, cost zero. It is not an invoice nor a verification of the account balance.

Why not use a managed agent in the cloud?

Because managed agents connect their tools through MCP servers with a remote URL and per-session authentication, and our connector to the ERP runs in a local container with no exposed ports. Without a persistent, authenticated remote gate, that route does not exist. We chose a local, finite process that starts with a click and ends on its own.

What happens if the worker fails in the middle of a cycle?

The design is fail-closed. If the outcome is uncertain, the ledger keeps the full budget reservation and blocks the next cycle until a person reconciles. There are no automatic retries and no model fallback. A lock abandoned by a crash requires confirming that no process is active before recovering it by hand.

Does this already work with the computer off?

No. The worker needs the computer, Node and the connector's container running. It is not installed as a service or a scheduled task, and there is no remote deployment. It is a known, documented limitation; moving it to a remote executor first requires an authenticated gate and a capacity measurement.

What do you mean by "respect for artificial intelligence"?

Operational respect, not fear and not worship: treating a system that acts faster than we can supervise with limits written before switching it on, evidence for every claim and a person who decides the only irreversible step. It is the same discipline demanded of any automation with access to production.

About the author and Transgenia

Efraín Carreón Ortiz is Managing Director of Centrum Transgenia, a Mexican technology boutique, and carries most of the company's sales. He holds the official Claude Code badge (Claude Partner Badge) issued by Anthropic, verifiable on Credly.

Transgenia is an OpenAI Select Partner within the OpenAI Partner Network and a registered partner in Anthropic's Claude Partner Network. Team: Víctor Estrada Bello, Chief PMO; Danild Johan Zambrana López, Chief Technology Officer; Jaime Lozano Castañeda, Chief Marketing Officer; Efraín Carreón Ortiz, Managing Director (Chief Executive Officer).

Let's talk: contacto@transgenia.org, WhatsApp +52 55 8034 0405, 15-minute call or the contact page.

Keep reading

Governed AI sales agents for B2B in Mexico: how we designed an SDR: the demo motion, the hard rules and the half-year goal this pilot inherits.
How Transgenia runs with governed AI agents: the draft-first and sign-off model we demand from any integration.
Who integrates Claude or ChatGPT with Odoo in Mexico? Hiring guide: what to demand in writing from any provider, Transgenia included.
MCP infrastructure inventory: the map of connectors and permissions we made before this pilot.
What to isolate before testing an AI agent on an Odoo copy: the safe test before any write.
We published MCP-Odoo-Tools: the open-source MCP server the scoped connector derives from.
AI implementation and Odoo integration: the offer and the form to request an assessment.