Letting any employee build an AI agent has become one of the most common startup pitches, but few companies have pushed the idea into wide production use. Gumloop, an agent builder used at Shopify, Gusto, and Instacart, is one that has. Its path suggests that winning large companies depended less on raw model capability than on two design choices: putting agents inside the tools people already use, and giving IT teams firm control over security, data access, and cost.
From a node editor to autonomous agents
When Gumloop applied to Y Combinator’s Winter 2024 batch, it was called Agent Hub. Before AI agents were widely understood, some people mistook it for a real estate agency.
The first product was a workflow automation tool, not an agent. Users wired together nodes in a visual editor and spelled out every step of the logic. Language models were not yet reliable enough to run a whole task on their own, so the team kept AI to narrow slots inside fixed, predictable workflows. That kept results dependable and costs low.
As models got better at reasoning and following instructions, the team added agent capabilities to the same builder. Users no longer had to configure every intermediate step, because the agent could work through the task itself. Adoption and usage then rose sharply. In effect, Gumloop shipped what the technology could support at the time and upgraded the product when the models caught up.
Today a user creates an agent through a chat-style interface and picks the work apps it should connect to from a library of prebuilt connectors. Agents can be deployed into Slack or Microsoft Teams, where teams already talk. For engineering teams, Gumloop offers an SDK, REST APIs, and hundreds of integrations exposed through Model Context Protocol servers. MCP is a standard way for AI systems to reach outside tools and data.
Why hobbyists gave way to enterprises
Early growth came from indie hackers, solo developers, and productivity enthusiasts. One early example transcribed two-hour Dungeons & Dragons sessions, summarized them, and emailed the notes to every player. Uses like this were novel, but they produced little economic value and were hard to standardize.
The turning point was an Australian health tech company that used Gumloop to automate complex research pipelines, gathering messy web data and structuring it into clean repositories. It showed that businesses would pay far more for a tool that removed expensive operational bottlenecks. In the first year, the CEO ran roughly 1,100 discovery and onboarding calls, using each one to test which features made business users lean in.
The first marquee customer, Instacart, did not come from a sales campaign. A single enthusiastic employee started promoting Gumloop in an internal Slack channel, ran training threads, and showed colleagues working automations. Usage spread across departments. Gumloop later hired that employee, who then taught the founders how enterprise procurement and sales work.
Shopify followed through a referral from someone at Instacart. Shopify trialed several automation tools in the same week, watched which one spread most naturally inside the company, and then opened Gumloop to between 4,000 and 8,000 employees overnight. Thousands of people built their own automations without hand-holding, which confirmed the product could stand on its own. Shopify later invested in the company.
▲ Word-of-mouth adoption inside a company
What large customers actually demanded
Selling to large public companies widens the requirements far beyond automation features. Gumloop had to build the following.
| Requirement | What it does |
|---|---|
| Role-based access control | Limits features and data by job role |
| SAML single sign-on | Lets staff log in with one company account |
| SCIM provisioning | Creates and removes user accounts automatically |
| Audit logs | Records who ran what and sends it to the company’s data lake |
| Private cloud hosting | Runs the platform inside the customer’s own cloud |
| Custom API keys | Connects the customer’s own model contracts |
Customers also asked for fine-grained isolation, such as giving outside contractors access to only certain features. Building controls whose job is to switch off powerful features felt frustrating to the engineers at first, but it proved to be a condition for enterprise adoption.
Even something as simple-sounding as browser automation needs a large governance layer underneath. IT administrators must be able to approve which websites agents may visit, block actions they have not allowed, and review what happened. Gumloop built session replay so administrators can inspect individual runs or audit 5,000 parallel sessions for cost and safety.
Designing for adoption, not just capability
The biggest unlock for employee adoption, according to the founders, is placing agents where people already work. Every trip to a separate portal adds friction. When colleagues with the same job ask an agent questions in a public Slack channel, others pick up the habit by watching.
The blank canvas problem, where users stare at an open-ended builder and do not know where to start, was handled with templates and workshops. When the company had only three templates, a Y Combinator partner told the founders to build at least a hundred. Gumloop now runs a large template gallery and use-case pages. In workshops with customer teams, it simply asks what people would automate if they had a magic wand, which tends to surface dozens of ideas at once.
Pricing changed along the same lines:
- Gumloop launched with $20 and $40 monthly plans modeled on consumer tools such as ChatGPT Plus.
- Seeing that businesses got far more value, it doubled prices three times during its Y Combinator batch.
- After a credit-based phase, it moved to cost-plus pricing: tokens, compute, and third-party APIs are billed at cost, plus a separate orchestration fee.
The founders argue that per-seat pricing hurts adoption because managers start rationing seats and employees hesitate to try the tool. Passing costs through openly, they say, makes Gumloop look like infrastructure, in the same category as Vercel and Cloudflare, rather than a software vendor hiding its margins.
Model choice and cost control
Gumloop supports Claude, OpenAI models, Amazon Bedrock, and companies’ own model gateways, and lets customers switch models with one click. The company describes itself as a neutral platform, like Switzerland. It pairs this with an idea it calls agentic sovereignty: a company should own its database, execution traces, credentials, and integration logic inside its own private cloud, so it is not locked into one model provider. The founders expect model labs to keep building applications that compete with their own API customers, which in their view makes that ownership more important.
Model choice is also a cost question. A high-stakes task such as building a growth model for a board deck calls for the latest frontier model, meaning the most capable top-tier model available. A support triage workflow that runs 80,000 times an hour needs a small, cheap model instead. In Gumloop’s experience, employees left to their own choices will route almost everything to the most expensive model, so administrators need central controls over which teams and tasks can use which models.
▲ Routing tasks to large and small models
Bottom-up interest, IT-led rollout
Enterprise interest usually starts with one employee who discovers Gumloop on X or LinkedIn. Without IT, though, that momentum stalls. A pilot cannot connect to real company tools until IT provisions API keys, database access, and single sign-on. Once IT leaders see that Gumloop can pull scattered AI subscriptions into one compliant, auditable hub, they often become its strongest internal champions. In one customer’s pilot, a small sales team generated three times more pipeline revenue in a single week than in the previous three months combined. That is one company’s result, not a typical outcome.
Leadership matters too. At AI-forward companies like Shopify, executives cleared the way quickly. At a large European health tech company, organizational rigidity and IT resistance slowed deployment.
Gumloop’s pitch to executives rests on one thesis: the people who do a workflow every day should be the ones who automate it. The pattern it wants to replace is familiar. A marketing operations team spends weeks writing specifications, hands them to engineers or expensive outside consultants, and gets back a half-finished pipeline.
Running a small team like a large one
Gumloop runs on its own product. An internal data agent connects to every company data source, so staff can ask a question in Slack and get a complex multi-database answer in about 20 minutes without a data analyst. Sales prep, alerts about customer usage spikes or drops, and the logistics of education cohorts held every two weeks are all automated. The core engineering team of eight delegates long-running tasks and testing to agents, and the founders say each engineer produces the output of about five, for a combined 40.
The founders once posted that they wanted to stay a ten-person, billion-dollar company. When Gumloop closed its Series A, the team was just the two co-founders and two interns. Enterprise sales brought heavy support, security, and integration work, and the company now has 45 to 50 people. It measures efficiency instead by whether customers assume it has 250 to 300 employees. The founders name brand awareness as the main constraint today, followed by engineering capacity for hundreds of pending feature requests, not model quality.
On fundraising, they found a live demo about 100 times more persuasive than a pitch deck, because nearly every startup now claims to automate work. After the seed round, later rounds led by Nexus and Benchmark were preempted without a formal deck or process.
Key takeaways for builders and buyers
The lessons from Gumloop’s growth line up as a short checklist:
- When models are weak, earn trust with fixed workflows, then expand to agents as models improve.
- If you sell to enterprises, treat access control, single sign-on, user provisioning, audit logs, and private hosting as core features.
- Put agents inside tools employees already use, and let colleagues see each other’s agent use in shared channels.
- Ship many templates and run workshops that ask teams what they would automate.
- Start pilots with IT so permissions and data access are solved first, and set which teams may use which models.
- Keep the ability to swap models and own your agent data so no single provider can lock you in.
If your company is evaluating an agent platform, the first questions may matter more than which model it runs: can the people closest to the work build agents themselves, and can IT govern what those agents do?