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 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, and the API is now a native tool your workers can call. No hand-written JSON, no glue code.
That removes most of the busywork. But 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 person.
- 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, and 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 step by step — 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 widen it as trust builds.
That last part is 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 give 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 give a clean tool; a weird, undocumented endpoint means you'll still be nudging it.
- It's a hosted platform, so treat sensitive data like you would with any vendor.
None of that is a dealbreaker for how I use it, but "hire a worker" doesn't mean "skip the judgment."
The shift
Once tools stop being infrastructure projects and workers stop being prompts, you stop thinking in automations and start thinking in roles. Who owns this outcome? What do they need to do it? Where do they need my sign-off?
You're not building workflows. You're growing a team — one hire at a time.