Agentic Company — turning wish → recipe → scheduled job

Since mid-July, ANDAFACIL (a mobility-equipment retailer in Mexico) has run most of its back office through an AI team: named agents for marketing, support, finance, tech and design, 158 scheduled jobs on one Mac, and a rule that anything public, paid or irreversible stops for a human OK. I packaged the setup as a playbook other businesses can reuse. This article is the part the playbook does not show: what the logs say after three months, and which design choices I would change.

The setup, briefly

1. Wish. One sentence describing an outcome on repeat: “Every Monday, gather last week's reviews, summarize the themes, draft two posts, and don't publish until I approve.”
2. Recipe. The wish turned into a script with explicit inputs, outputs and a stop point. Recipes live in the repo next to the rules that constrain them (cost gate, approval gate, no customer data in public output).
3. Job. A scheduled run of the recipe (a macOS LaunchAgent with catch-up if the Mac was asleep). Every run logs a task under the owning agent.
4. Gate. When a recipe reaches something a human must decide, it creates an operator task or sends an approval email with a public magic link, so the decision does not depend on the Mac being online.

What the logs say

Finding 1: the agents are not the bottleneck, the human queue is

Agents completed 11,764 tasks. The human completed 147. That ratio is the point of the system, but the open queue shows where it breaks: 611 operator tasks are open, and two-thirds are more than two weeks old. Median time to close a human task is about 3 hours; the 90th percentile is 11 days. Whatever the agents hand to a person either gets done the same day or effectively never.

The tasks that do get closed share a property: they are tied to a condition the system can recheck. “Order never processed”, “marketplace push failed”, “stock channel stale” — when the condition clears, the task closes. Nearly all of the closed tasks come from sources of that kind. The tasks that pile up are reminders: “check the expenses folder”, “run the tax download”, “sync the tag manager if tagging changed today”. Nothing can tell whether they were done, so nothing closes them.

Finding 2: recurring jobs create a new task every day

The worst offenders are idempotent in the wrong way. Each run creates a task keyed by date, so the key never collides and a fresh task appears every day:

source                  open  distinct keys  first open
daily_expenses_check      79             79  Jul 23
sat_descarga_daily        47             47  Jul 28
daily_gtm_sync            43             43  Jul 15

Seventy-nine copies of “check the expenses folder” are not 79 pieces of work. They are one piece of work and 78 units of noise that hide the tasks that matter. The same pattern hit the sales side: a lead-follow-up job opened 69 “call this distributor today” tasks in three days. A queue that grows faster than a person can read it stops being read.

The fix is a design rule, not a cleanup script: a recurring check owns one open task. Key it by job, not by date; update the body and a “last seen” timestamp on each run; close it automatically when the underlying condition is satisfied (the folder is empty, the download log has today's file). If the job cannot detect completion, it should not create a task at all — it should be a checklist item in a daily digest.

Finding 3: the activity log measures logging, not work

81% of agent tasks have identical start and end times, because most are written once, after the fact, as “completed”. That makes the log useful for counting and attribution (which agent, which workflow, which skill) and useless for duration or throughput. Separately, 214 tasks are stuck in “started” because the process that opened them died or never sent the matching “completed” event. Nothing sweeps them.

The same is true of cost tracking. The rule says every paid API call gets logged. In practice 97% of tracked spend is an estimate reconstructed from usage counts, and only a few dozen rows are exact amounts. The estimates are good enough to answer “is this job expensive?” but not to reconcile against an invoice.

Finding 4: what held up

• The approval gate. Public posts, ad launches and price changes stop for an explicit OK, and approvals happen through a public page that works from a phone with the Mac off. A test fails the build if an email ever links to a Mac-only address.
• Named owners. Attributing every task to a teammate (SofIA for marketing, SebastIAn for tech, EmilIAno for finance) made it obvious which areas generate the most human work: finance alone owns 330 of the 611 open tasks. That is a staffing signal, not just a log.
• Hard caps in code. Budget limits live in config files pinned by tests. An agent that wants more ad spend cannot raise the cap; the test fails and the change is reverted.
• Low failure rate. 1.3% of logged tasks failed, and failures are visible on the dashboard with the owning agent.

Implementation takeaways

1. Design the human queue before the agents. Decide how a person will see, prioritize and close work, and cap how many open items each source may hold. Agents will happily fill any queue you give them.
2. One open task per recurring check, closed by the system. Key tasks by job, update in place, and auto-close when a verifiable condition clears. If completion cannot be detected, put it in a digest, not a task.
3. Log start and end as separate events, and sweep orphans. Write “started” when work begins, “completed” or “failed” when it ends, and run a nightly job that marks anything started more than a few hours ago as abandoned. Otherwise your log can count tasks but cannot time them.
4. Log costs from the API response, not from memory. Most providers return usage on every call. Record it in the same wrapper that makes the call, so exact cost is the default and estimates are the exception.
5. Gate by consequence, not by agent. “Anything public, paid or irreversible needs an OK” is a rule every new recipe inherits. Per-agent permissions drift; a consequence rule does not.

If you want to copy it this week

• Run one query: open human tasks grouped by source, with count and distinct keys. Any source where those numbers match and the count is above five is a recurring job creating duplicates.
• Add a max_open per source to whatever creates tasks. When it is reached, update the oldest task instead of creating a new one.
• Write down three actions in your business that are public, paid or irreversible, and put an approval step in front of each before you automate anything around them.
• Start with one wish, one recipe and one job. Measure how many human tasks it creates per week before you add the second.

The surprising lesson from three months is that the AI side scaled without drama: thousands of tasks, a low failure rate, and real work getting done overnight. The part that needed engineering was the interface back to the one human in the loop. An agentic company is limited by how much decision-making it can route to people — so design that channel as carefully as the agents.