Not every AI feature needs an agent

Anthropic's foundational guide to building effective agents, published in December 2024, draws a useful distinction. In a workflow, the model and tools run through code paths you define. In an agent, the model directs its own next steps and decides which tools to use.

The guide's practical advice is to start with the simplest approach and add complexity only when the problem needs it. Sometimes that means no agent at all.

These aren't levels you have to climb. They're different ways of organising an AI feature. Handing more decisions to the model can mean more requests, more accumulated context and a less predictable run. It depends on the design; a model can also return more than one tool call in a single response.

Message Yourself OS reads my WhatsApp and tells me who's waiting on me and what I promised. Every chat is indexed on my machine. In the ranked mode I'm testing, the flow looks like this:

The model never decides which chats to open. Code does, with rules I can read and explain. Those rules don't understand meaning; they look for signals like a question mark or the words "I'll" and "I will". Understanding whether a message is really a question for me or a promise is the model's job. Code then checks the evidence and sender.

One thing to be clear about, because this is WhatsApp: indexing and scoring happen on my machine, but the messages in the chats that make the shortlist do go to the model provider. The bot now uses Groq, with OpenAI as fallback. Local indexing means the model sees a shortlist, not that it sees nothing.

I should also be honest about the plan the bot used. Until November 2026 it ran on Gemini's unpaid quota. Google's terms say content sent through unpaid services can be used to improve Google products and may be reviewed by people, and they ask you not to submit sensitive, confidential or personal information. My shortlist contains other people's messages, so I've switched the bot's default provider to Groq. Groq's documentation says it doesn't keep inference inputs or outputs by default, may keep logs for up to 30 days when it investigates reliability or abuse, and lets every customer turn on Zero Data Retention to stop even that, which is how the bot's account is set. Read the terms for every provider in your own fallback chain before sending real messages; mine still has OpenAI as a fallback. The public demo below uses only made up chats. Google's Gemini API terms and Groq's data controls explain the details.

To make the difference concrete I built a small demo: twelve made up chats, and the same triage task done twice. The code, prompts, settings and raw traces are on GitHub.

The workflow ranks chats with the same point rules, sends only the ones that qualify, makes one model call with a JSON schema, and checks the quotes in code:

const ranked = pickCandidates(chats, today);
const reply = await model.generate({
  system,
  turns: [{ role: "user", text: prompt }],
  jsonSchema: findingSchema,
});
const findings = verifyFindings(parseFindings(reply.text), chats);

The agent gets three tools (list_chats, read_chat, finish) and a loop. It decides what to read, one step at a time, until it calls finish or hits 15 steps:

for (let step = 1; step <= maxSteps; step++) {
  const reply = await model.generate({ system, turns, tools: agentTools });
  const finish = reply.toolCalls.find((call) => call.name === "finish");
  if (finish) return verifyFindings(finish.args.findings, chats);
  for (const call of reply.toolCalls) {
    turns.push({
      role: "tool",
      name: call.name,
      result: runTool(call.name, call.args, chats),
    });
  }
}

Both end with the same check, so the comparison is fair in one important sense: same chats, same model and same rules for checking evidence. For each finding, the check confirms that the quote appears in the named message and that the sender matches the claim: a promise has to be a message I sent; "waiting on me" has to be a message someone else sent. That verifies evidence and attribution. It doesn't prove the model understood the meaning correctly.

In this implementation, each agent step makes another model request and sends the conversation so far again. That is why its input token count grows as it opens chats, while the workflow sends its shortlist once.

Added up across its calls, the agent's input came to about 4.1 to 5.3 times the workflow's for the same twelve chats. That number is cumulative across requests, not one large context window. Every request also counts against the provider's rate limits. The demo waits only when a provider returns HTTP 429, uses the delay the provider supplies and records it. In these back to back Groq runs, the agent waited up to 29 seconds; the workflow waited once, for 10 seconds. In the Gemini run, my project showed a five requests per minute limit for that model, and the agent's sixth request waited 94 seconds. Those are the limits I saw on my accounts that day, not fixed limits for everyone. Groq's documentation explains that its limits vary by model and account: Groq rate limits. Google's quota documentation works the same way: Gemini API rate limits.

The bigger surprise was what it found. In every run the agent listed the chats, opened Riya, Mom, the team standup and usually the recruiter, all chats where someone asked me something, and then decided it was done. It wasn't forced to read every chat. It could call finish when it thought it had enough, within the 15 step limit. That's the decision I had handed to the model, and it stopped before reaching the two chats that mattered. It never opened Arjun's or Neha's chats, where I had made promises. So it missed both promises in all three Groq runs and in the Gemini run. On Gemini it also labelled the standup message "can you share the deploy notes before 4?" as a promise I made. The quote check caught that because the message wasn't sent by me.

The workflow found both promises in every run because my ranking gives my last message containing "I'll" or "I will" the same 14 points as a message ending in a question mark. Both chats qualified, so the model saw them. The rule is in code; it doesn't depend on the model remembering to look.

The check has limits too. In one run the workflow listed Arjun's "Bro the API docs link is broken" as waiting on me. The quote is real and Arjun sent it, so it passed the evidence check even though it isn't really a question. Code can check evidence; it can't check judgement.

A workflow can fail too. If my scoring rules are wrong, a chat that matters never reaches the model, and nothing downstream can bring it back. Someone who writes "kal tak bhej dunga" instead of "I'll send it tomorrow" scores no promise points in my rules. An agent can adapt to things my rules never anticipated.

That's the real tradeoff:

• Workflow: you encode more of your assumptions in code.
• Agent: you hand more decisions to the model.

Neither removes failure. They move where the failure happens. For my inbox I'd rather have failures I can find by reading my own rules than failures I have to dig out of a trace.