The tools I give every agent I run

Claude Code, Codex, something I wrote myself: in a normal week I’m in three or four of them, and the model underneath is more or less the same model. What decides whether a session goes anywhere is what it can reach.

So I keep the same five things plugged in everywhere. Search, data, storage, deploys, cheap model calls. None of them care which agent is calling, which is the whole point, and each one is a key in a .env plus a page of notes rather than something I have to set up again per harness.

Linkup, so web search doesn’t depend on the harness

Every agent has some web capability and you never quite know what it is. Does it fetch the page or a cached copy? Does it follow the link it found? Does it quietly give up on a 403 and answer from memory?

Linkup is a search API built for models to call. One query, and you choose the shape of what comes back:

• Ranked URLs, when you want to pick the sources yourself.
• A sourced answer, when it has already read across several pages and you want the conclusion with its citations.
• Structured JSON, against a schema you pass in.

The third is the one I use most. It arrives as data, so a script can use it directly instead of an agent reading prose and retyping the fields into a file. There’s also a fetch endpoint that turns a known URL into clean markdown in about a second, which is the honest version of “read this page”.

The reason this beats the built-in tool isn’t quality, it’s that it’s the same everywhere. Whatever I opened this morning, web search works and works the same way.

Apify, so any platform is reachable

Apify is a marketplace of scrapers, and there is one for almost anything. My own LinkedIn posts with their real numbers, a YouTube channel’s videos, the comments under them, transcripts, thumbnails, job listings.

That first one comes up more than I expected. When I’m planning content, being able to say “go get the actual figures on my last twenty posts and tell me which openings worked” beats any dashboard, because the answer arrives as a table I can then do something else with.

What makes it usable is the rules, which live in a skill file the agent reads before it touches the API:

• A table of approved scrapers, one row per platform, with its price per result and a payload I’ve verified. For those it just runs, no questions.
• Only per-result pricing. Plenty of scrapers want $25 a month up front, which defeats the purpose of reaching for one twice a year. It’s a hard filter: check the pricing model, and if it’s a subscription, move to the next one.
• Read the input schema, don’t guess field names. maxItems doesn’t exist in the LinkedIn scraper, it’s maxPosts. Finding that out through a failed run costs a run.
• Always set the cap. A keyword search with no limit can return thousands of rows and bill every one. It’s the only mistake in this whole setup that costs real money.

And for a platform that isn’t in the table yet:

1. 1Search the storePer-result pricing only
2. 2Read its input schemaWrite the payload from the real fields
3. 3Run three, on five rowsCompare what actually comes back
4. 4Scale the winnerThen add it to the table

Softr, so there’s somewhere to put things

An agent that finds things needs somewhere to keep them, and it has to be somewhere I can open too. A JSON file on disk fails that: nobody sorts a file, or filters it, or fixes one cell in it. A Postgres with fourteen tables I didn’t design fails it differently.

A Softr database sits in the middle. The agent reads and writes through the API. I open the same table in a browser, sort it, filter it, correct a row, share a view with someone who needs to look at it. That second half is what people skip when they pick a store for an agent, and it’s the half you end up using daily.

I work at Softr, so take the recommendation with that in mind. The reason I’d still pick it is the rate limits, which are unusually generous for this kind of use: 40 reads a second and 30 writes a second, per token. An agent looping over a list never hits them.

A lot of projects also never need an interface at all. It’s me and the data, or three people and the data. The database is the product, and building a front end for it would be work nobody asked for.

Cloudflare, so an experiment can become a URL

For everything that shouldn’t stay on my laptop. A Worker takes about a minute: enough for a page, a small API, or an agent I want to poke at over HTTP using their SDK.

It matters less for what it does than for when it happens. An experiment that can be online in a minute gets shown to someone; one that needs a deploy story dies in the folder it was born in.

OpenRouter, so the big model doesn’t do everything

The obvious reason is access to every model behind one key, and that’s true, but it isn’t why it’s on this list.

The real reason is that some work shouldn’t happen inside the agent’s conversation at all. Say you’re cleaning 200 rows. If the agent does it turn by turn, that’s 200 turns in one context that grows the whole time, each one re-reading everything before it, on the most expensive model you own. If it instead writes a script that fires 200 small calls at a cheap model, each call sees one row, they run in parallel, and the result lands as a file.

What the script sends

• One row per call
• 200 calls at once
• No shared context

OpenRouter

• One key, one bill
• Switching model is a string
• Fallbacks when one is down

What it reaches

• A small fast model
• A frontier one when needed
• Whatever shipped last week

This is also how I try a model I’ve never used. Change one string, run the same script, compare it against the last one. The account and the key stay the same.

The notes matter as much as the keys

None of this lives in my head, and none of it lives in a harness either. Each tool gets a skill file: what its key is called, the endpoint that actually works, the limits, and the mistakes I already made.

The Apify one carries the scraper table. The Softr one records that GET /fields returns a 405 and the schema comes from the tables endpoint instead. Small things, but an agent that has to rediscover an endpoint every session will eventually rediscover it wrong, and tell you it worked.

I wrote a while back that MCP servers were the last part of my setup that was still tool-shaped instead of file-shaped, because every harness needs them configured separately and they drift. A key in a .env and a Markdown file next to it don’t have that problem. Any agent that can read a file and run curl has the whole toolbox, and moving to a new one costs nothing.

What I haven’t tried yet

Monid aggregates Apify, Apollo and a few hundred other data providers behind one balance, so you pay per call rather than subscribing to each. They describe themselves as OpenRouter for agent tools, which is roughly the thing I said I wanted. I haven’t needed it enough to test it properly, so I can’t tell you whether it holds up. It’s next on the list.

That’s the setup. Five keys and a few pages of notes, and I stop having to check whether today’s agent can reach the thing I need.