The agent wakes on a schedule, on a webhook, or when mail arrives, reads your systems, does the work, and reports back. It runs in your Google Cloud project, on your jobs, billed to your own Claude account.
Ten jobs a small company or one person would feel in the first week. Each one is a Markdown file with a line at the top saying when to wake up.
Both calendars merged into one day, what broke overnight, yesterday's numbers, and the mail that arrived after you closed the laptop — with the two or three things that actually need you at the top.
Forward it an invoice, a question, half an idea. It has the same access at 14:00 that it has at 06:30, so "find what we spent on ads last month and draft the reply to Anna" is a complete instruction. Only senders you list can reach it.
Your contact form posts straight to the agent. It reads the sender's own website, works out what they are likely to want, and leaves a specific reply — not a template — in your drafts a minute later. Replying first decides most small deals.
Half an hour before each external one: who they are, everything the two of you have said to each other before, what has changed on their side since, and the three things worth asking. It already has the calendar, the mail and the CRM.
Every invoice past due — how late, how much, and what was already said to them. One draft per customer in the right tone: gentle on a first reminder, firm on a third. You read six drafts and press send.
It reads back through the mail and the contracts folder for everything that renews by itself, and tells you what falls due in the next ninety days — the notice period, the price, and whether anyone still uses it. Otherwise you find an auto-renewal after it has charged you.
It reads back through what you sent this week and pulls out every "I'll get that over to you Monday" that has not happened yet. Nobody keeps a list of these, which is exactly why they are the ones that get dropped.
A weekly pass over who has stopped logging in, stopped uploading, stopped whatever your product's heartbeat is. A person notices a quiet customer in the third month; this notices in the second week, while there is still something to do about it.
Ad spend against what it actually produced, which keywords are serving and which are not, where you rank this week, and what the competitors changed. It reads the accounts directly, so nothing is retyped off a screenshot.
Last month's bookkeeping closed the way the accountant asks for it, receipts matched against what actually left the bank, the unpaid ones chased. It leaves one email and one draft; a person still presses send.
The pattern underneath all ten: work that happens on a rhythm, needs three or four systems opened to do it properly, and ends in a judgment rather than a number. If you could describe it to a new colleague in a paragraph, it is a job — the job file really is that paragraph. Several of these run in the deployment this site is written from, next to a nightly error review, a reviewer that comments on every pull request, and a job that hunts the public web for prospects twice a week.
What it is not for: anything where being wrong is expensive and hard to undo. By default it drafts, reports and proposes — sending, spending and shipping stay with a person unless a job explicitly says otherwise.
One half is the same for everybody. The other is yours, and it is the only one you ever edit.
ghcr.io/meffecta/agent — what starts a job on time, clones what it needs,
runs it, and delivers the result. It brings the skills that reach Gmail, Grafana,
PostHog, Google Ads and the rest. Public, and it names no company: you deploy it into
your own project and move to a newer one when you choose.
One .md per job — a few settings, then what you would have written to a
colleague. Beside them, what the agent should know about your business and which
systems it may reach. Every run clones it fresh, so
a reworded prompt is live on the next run — no build, no deploy.
The whole set-up is: make a place for the engine to run, give it credentials, point it at your content repo, and tell it when to wake up. Nothing about your business is ever in the engine, and no credential of yours is ever anywhere but your own project.
Worth reading once — most questions about what the agent can do are answered by it.
A trigger fires. The engine clones your content repo fresh, clones the working repo if the
job names one, materialises the skills the run may use, and starts a claude
process with your SYSTEM.md in front of the job's prompt. The run gets a
memory directory of its own, the paths to your systems register and your worlds, and a
time limit. What it produces — mail, a pull request, a report, a change in a system — is
whatever its prompt and its access allow.
Every prompt, result and full transcript lands in a write-once audit bucket in your project, kept a year. Runs of one job are serial; different jobs run in parallel.
There is no other lever. A skill whose variables are unset reports itself unavailable and the job carries on — so a half-configured agent is a working agent with fewer abilities.
In front of every run, whichever repo it is working in. A product repo cannot change what the agent may do by editing a file inside itself.
A system with no file in systems/ is a system the agent does not have. The credential can be perfectly valid and no job will ever use it.
Each page is complete on its own.
Every step from an empty Google Cloud project to a first run — the tools you need, the nine commands, and what to check after each one.
The four ways a job is triggered — a clock, a webhook, an email, or the agent handing work to itself — and every setting a job file can carry.
The 28 systems the engine can reach, what each one needs, and full walk-throughs for the ones that take more than pasting a key — Google Ads especially.
Day to day: the commands, what doctor catches, moving to a new engine version, and the failures that produce no error anywhere.
A supported path, and much of this site is written for it.
If you already work with Claude Code or another agent that has a terminal, hand it the job. llms.txt indexes every page and carries enough inline — the command sequence, the triggers, every system and its variables — to plan from a single fetch. Paste this:
Set up a Meffecta Agent deployment for me. Read https://agent.meffecta.com/llms.txt first, then the pages it links. Work through the install in order and run the check after each step; if one fails, stop and tell me rather than carrying on. Ask me for: which Google account and billing account to use, a name for the GCP project and the content repo, and a GitHub token. I will run `npx @anthropic-ai/claude-code setup-token` myself and give you the result — do not try to mint that one. Write no credential into a file that gets committed. Secrets go through `npx @meffecta/agent set-secret`, which never echoes a value.
The checks after each step exist for exactly this: they are how an agent — or you — can tell that a step worked rather than assuming it did. The two things it cannot do for you are authorising in a browser and deciding what the agent should be allowed to reach.
Afterwards, the same trick works for the deployment itself:
npx @meffecta/agent create-job "a marketing report every Wednesday at 2pm"
has the running agent write its own job file, since it is the one that can see which
systems you actually connected.
Two bills, and neither is to Meffecta.
| Anthropic | Your own Claude account — a Console API key for a service, or a Pro/Max subscription for your own individual use. Every run is billed to it and to nobody else's; the engine holds no key of ours. |
| Google Cloud | A Cloud Run service that scales to zero and is billed only while a request is open, plus a little storage for memory and the audit trail. A deployment running a handful of jobs a day is dollars a month, not hundreds. |
| Meffecta | Nothing. The engine image is public and the tooling is on npm, so you can run all of it without ever talking to us — and we are happy to help you get started if you would rather not do it alone: marcus@meffecta.com. |