I stopped writing automations and started hiring AI workers

andreysparish — Sat, 04 Jul 2026 09:33:31 +0000

title: "I stopped wr
Most "AI at work" is still a chatbot in a corner: you ask, it answers, the work is still yours. I wanted the opposite — something I could hand a whole task to and get a result back, not a suggestion.

So instead of building automations, I started hiring workers. Here's what that actually means in practice, and where the useful parts are.

First: any API becomes a tool, with no code

Before a worker is useful, it needs things it can do. The usual way to give an AI a new capability is to write an integration — read the docs, model the endpoints, wire the auth, handle errors. An afternoon each.

Instead: paste a domain. If the model already knows the API, you get a working tool immediately. If it doesn't, it searches, scrapes the docs across pages, and assembles the endpoints into one schema. Add the key, activate, done — the API is now a native tool your workers can call. No hand-written JSON, no glue code.

That alone removed most of the busywork. But the connectors are just the raw materials. The interesting part is who uses them.

Hiring a worker

A worker isn't a prompt. It's a hire with:

A role. What it's for, what "good" looks like, and where its boundaries are. This is the part that decides whether a worker is useful or useless — same as hiring a human.
A brain you choose. Each worker runs on the model you pick — Claude, GPT, or Gemini — so you can put a strong-reasoning model on the tricky role and a cheaper/faster one on the repetitive one.
Tools it's allowed to use. You hand a worker exactly the capabilities its job needs, and nothing else.

The tool set a worker can be given is the point:

Email — read an inbox, send and reply over IMAP/SMTP.
Webhooks — an external event can wake a worker and hand it the payload to act on.
Memory — a worker remembers across runs, so it doesn't repeat itself or lose the thread of a project.
File storage — durable storage that survives restarts, for the documents and artifacts a worker produces.
Site logins — you store a worker's credentials for third-party sites (encrypted, write-only — the password is never readable back), and it can log in and do real work on those sites on your behalf.

Tasks: work that starts without you

A worker owns tasks. A task runs on a trigger, not on you sitting there:

on a schedule (every morning, every two days, whatever the cron says),
when an email lands,
when a webhook fires.

So a content worker can draft and publish on a cadence; an inbox worker can triage mail as it arrives; a monitoring worker can react to an event the second it happens. You come back to results.

The supervisor: staying in control of the team

Handing autonomy to software is only comfortable if you can rein it in. That's the supervisor layer, and it's the thing I'd have refused to run without:

Hire and fire. Spin up a new worker for a role, pause one, or retire it entirely.
Assign and adjust tasks. Give a worker a task, change its schedule, edit its instructions, disable it.
Watch what it does. Every run is logged — you can see what each worker did, when, and why.
Approve the risky stuff. Anything that reaches the outside world (sending mail, publishing, posting) can go through an approval gate: the worker proposes, you approve, then it acts. You decide how much rope each worker gets, and you can widen it as trust builds.

That last part is what makes the difference between "an agent I'm nervous about" and "a teammate with a clear job." The worker does the work; the human stays the one who signs off.

Where this is honestly not magic

Worth saying plainly:

A worker is only as good as its role. Vague instructions → vague output. The org-design thinking doesn't disappear; it moves to you.
No-code connectors depend on the target API's docs. Clean docs → clean tool; weird undocumented endpoint → you'll still be nudging it.
It's a hosted platform and currently closed beta, so treat sensitive data and rough edges accordingly.

None of that is a dealbreaker for how I use it, but "hire a worker" doesn't mean "skip the judgment."

Try it

It's in closed beta — the first batch of builders get lifetime access to the core, plus some provider credit. If you want to build a small team that works while you sleep: (https://toolweave.dev/blog/en/build-a-team-of-ai-workers)

Question for anyone already running agents: what's the first role you'd actually hire for — inbox triage, a QA bot, a content worker, something else? And what would you not let it do without approval?