The version worth keeping is the selection question, not the tool.
For a long time, the conversation in our teams about AI automation followed a predictable arc: someone showed a demo, a few people got excited, someone built a Custom GPT (a chatbot-style AI assistant customized with instructions), the initial enthusiasm faded within a month, and we collectively concluded the product was slightly overhyped. Repeat.
What holds up on examination is that the failure was almost never the tool. It was the workflow selection. We were building for the most interesting workflows rather than the most agent-shaped ones — and those turn out to be genuinely different things.
The distinction that changes everything
An “agent-shaped” workflow has a specific signature: it involves repetitive information gathering, some synthesis or judgment, and an output that someone else acts on — and it happens on a schedule, not on demand. A chatbot interface can help with this kind of work, but only if someone keeps coming back to ask. The moment the automation needs to run unsupervised, the chatbot metaphor breaks.
That’s what makes one example from the Rippling sales team worth sitting with. A sales consultant there — no engineering background, no IT ticket — built an agent that researches accounts, summarizes recorded sales calls, and posts deal briefs into the team’s messaging channel for every active opportunity. It runs in the background. Nobody has to remember to ask it. The result is five to six hours reclaimed per rep per week.
The key word is “unsupervised.” The work was always agent-shaped. It just needed a tool that could act, persist context across steps, and run on a schedule without a human in the loop.
Custom GPTs never escaped what you might call the individual-skill ceiling: their quality was entirely a function of whoever wrote the prompt, and they required someone to keep the conversation going. The same task as an agent produces output that people actually use — because it shows up in their workflow rather than waiting for them to remember to visit a chat window.
Two questions before you build anything
The move worth making before touching any agent builder is to run two diagnostic prompts against a candidate workflow. Not to generate code — just to think more clearly.
The first prompt takes a workflow you’re considering and asks: is this actually fit for an agent, or is it better suited to a different kind of tool? A well-designed diagnostic will surface whether the task requires multiple steps in sequence, whether it can run without a human triggering it each time, and whether the output is something someone would act on rather than just read. A “fit” verdict is meaningful. A “not fit” verdict saves you an afternoon of building something that will quietly stop getting used.
The second prompt takes a “fit” workflow and produces a one-paragraph build specification — specific enough to paste directly into an agent builder. This matters more than it sounds. The agents that succeed tend to start from a clear, grounded spec. The ones that drift or underdeliver usually started from an exploratory conversation that never got specific enough. One paragraph is the right bar: if you cannot describe the workflow in one paragraph, you are not ready to build it.
Running both prompts in sequence takes about fifteen minutes. In my experience, that is the most valuable fifteen minutes you can spend before writing a single instruction.
The governance question worth asking early
One thing the enthusiasm tends to skip over: when you publish an agent inside a shared workspace, there is often a setting that lets the agent run with the builder’s own credentials. In practice, this means anyone running that agent is acting as the creator — including against any connected systems like a CRM (customer relationship management software) or ticketing platform.
This is not a theoretical risk. The scenario plays out like this: a sales consultant builds a genuinely useful account-research agent, publishes it with their own Salesforce credentials attached, and forgets about it. That agent is now running as them, against production data, across the team.
The right default is least privilege: limit the agent’s audience until you have verified what it touches, avoid sensitive connectors in early builds, and check what credentials are attached before sharing broadly. It is a ten-second review that most first-time builders skip.
Where this lands
The teams that get sustained value from automation stayed specific about which work they were automating and built a simple measurement into the first month. The teams that churned off picked the most interesting workflow, built quickly, evaluated by feel, and never revisited.
The infrastructure for workflow automation is maturing faster than most of our selection instincts are. The tool question — which platform, which interface — matters less now than the workflow question: is this actually agent-shaped, and do we have a specific enough spec to build it well?
That second question is where the five hours live.
Text summarized and optimized using Anthropic’s models and reviewed by a human.