Your AI agent shouldn't call tools one at a time: what Factory's Droid 1.0 means for bulk jobs

Ask an AI agent to move 150 records in a CRM and watch what it does. It reads one, thinks, updates one, thinks, reads the next. Every step is another trip to the model. By record 80 it's slow, it's expensive, and it's starting to lose track of what it already did.

This week Factory, the company behind the Droid coding agent, shipped a fix for exactly that pattern and made it the default. It's the most useful agent design idea I've read this month, and it isn't only for coding.

What happened

On 29 October Factory released Droid 1.0. The headline change is what they call programmatic tool calling. Instead of calling tools one by one, the model writes a short JavaScript program that calls the tools for it. That program runs in a sandbox with no file, network or system access of its own, so it can only use the tools Droid hands it. Only what the program prints goes back to the model.

Factory's own example: a clean-up job moved 151 Linear issues between queues and checked each move, 312 tool calls in all. They estimate that doing it call by call would take 36 model requests and around 3.1 million input tokens. The script took 2 requests and about 61,000 tokens: one to write the program, one to read what it printed. The script also compared 15 fields before and after every write and was written to stop at the first issue that changed in any unexpected way.

Those are Factory's numbers, and the direct-call side is modelled, not measured. They're also honest that the savings aren't everywhere: across Droid, script mode cut cost by 15% on Claude Opus 5.5, and most of that came from the 12.5% of scripts that made six or more tool calls.

The idea isn't new, and Factory says so. Anthropic already offers programmatic tool calling in the Claude API, where Claude writes Python that calls your tools inside a code execution container. Cloudflare has Code Mode, which lets an agent write code against MCP tools as typed functions. What's new is a serious agent product making it the normal way to work.

Why it matters for business automations

Most of the agent work I'm asked about isn't one clever answer. It's bulk work. Re-tag every lead from last month's campaign. Chase every unpaid invoice older than 30 days. Close every repair job that's been collected but is still marked "ready".

When the model drives every call, three things go wrong. Cost climbs because the instructions and history are re-sent on every request. The context fills with raw API responses the model doesn't need. And the model can quietly skip a case it planned to handle, because nothing forces it to finish the loop. A program doesn't get bored at record 97. If the loop says check every record, it checks every record.

That's the point I care about most: the reliable part of the job moves out of the model's judgement and into code you can read.

How I'd use this on a real system

I build on Laravel, MySQL and Vue, and a lot of that work is the kind of operational platform described in my field report on running a UK repair business on one platform: customers, repairs, bookings, payments and invoices in one place. If I were letting an agent do bulk updates on a system like that, this is how I'd set it up.

• Give the script narrow tools, not the database. Things like findJobs(filters), getJob(id) and setStatus(id, status), each backed by a proper Laravel endpoint with validation. No raw SQL, no open HTTP. Cloudflare's docs make the same point: keep credentials on the host side, outside the sandbox.
• Dry run first. The first run only reads and prints a summary: how many records match, a few examples, what would change. A person approves that before anything is written.
• Verify every write. Read the record back after the update and confirm that only the intended field changed. Stop on the first surprise, exactly as Factory's Linear script did.
• Cap the blast radius. A hard limit on records per run, small batches and rate limits that the API enforces, not the prompt.
• Log outside the model. Every call and result goes to an audit table the agent can't edit. The model only sees the short summary.

I already think about agents this way on my own site. The assistant there is a coordinator with a few specialists, and you can see its live counts and timings on the agent control room.

The pitfalls nobody mentions

A script makes good work faster. It makes bad work faster too. If the agent writes a wrong filter, it'll apply it to 400 records in the time it took to read this sentence. That's why the dry run and the cap aren't optional.

It's also overkill for small jobs. If a task needs three tool calls, calling them directly is fine, and Factory's own figures show the gains sit in the longer runs. I made a similar argument in my post on which workflow steps actually need an agent: match the tool to the size of the job.

And if your tools can write, the usual rules still apply. I covered those in how to open up MCP write access safely. A sandbox limits what the program can reach. It doesn't decide whether the change was a good idea.

A short checklist before you let an agent loop over your data

1. Is the job big enough? Roughly six or more tool calls, or a list of records.
2. Does the sandbox only see narrow, validated tools, with credentials kept outside it?
3. Is there a read-only dry run that a person signs off?
4. Does the script check each write and stop on the first unexpected change?
5. Are there hard limits on records, batch size and rate?
6. Is every call logged somewhere the agent can't touch?

My view is simple. Let the model plan, let code do the repetition, and let a person approve anything that changes real records. It's cheaper, easier to audit and much harder for the agent to quietly drop record 97.

If you've got a bulk job in your CRM, ERP or booking system that you'd like an agent to handle safely, have a look at the AI agent and integration work I take on, or book a call with me and we'll work out whether it needs a script, an agent or neither.