Building AI Agents for Everyone

Gumloop co-founders Max Brodeur-Urbas and Rahul Behal discuss how a visual workflow builder evolved into an enterprise agent platform, what they learned from more than 1,100 customer calls, how a power user at Instacart opened the door to enterprise sales, and why the people who understand a task should be the ones automating it. The conversation covers enterprise requirements, pricing transparency, model neutrality, and the IT-led buying dynamics that shape adoption.

14 min read
Building AI Agents for Everyone
source: https://www.youtube.com/watch?v=kDLji2s7LV4

Origins: from workflow automation to an agent hub

Gumloop started as a workflow automation platform with a visual builder, and the team was candid that the models of the time were not good enough to make agents work on their own. So they met the models where they were: AI was confined to the key steps that needed it, while everything around it was standard infrastructure built to be reliable and economical. Once agents became capable of completing tasks end to end, the manually assembled workflow became less necessary, and the product’s direction shifted accordingly. The company’s mission has stayed constant since the beginning, even as the name and surface changed.

How the product works

Users create an agent through a chat interface, connect the apps they already use through a set of connectors, and then either talk to the agent directly or add it to Slack or Microsoft Teams. The idea is to bring agents to where people already spend their day. Agents are team-specific: a sales agent might connect call recording, CRM, enrichment, and web search tools, carry the team’s playbook, and handle next steps, account deduplication, and call analysis. In practice it becomes a co-pilot that people ping in Slack and CC on email threads.

Gumloop positions itself as the connector between tools rather than a replacement for all of them. Some customers do cancel vertical SaaS contracts in favor of an agent, but more often the platform sits across data sources and lets teams keep the tools they like while consolidating the work in one place. For engineering organizations building internal tooling, the platform offers an SDK and API, and nearly everything possible in the UI can be done programmatically. Hundreds of integrations are exposed via MCP servers, so many customers use Gumloop as a base layer for their internal AI infrastructure.

Finding the enterprise market

The earliest adopters were individuals and indie hackers automating tedious tasks. One memorable example was a user transcribing Dungeons and Dragons sessions and distributing the notes to attendees. The turning point came with business users, such as an Australian health tech company that used the platform to pull and structure web research. The team realized enterprise customers would pay far more, and that the value delivered was deeper and more consequential.

The shift was gradual. The founders had always wanted a tool that a coworker or even their mother could use, but in pitches to organizations with thousands of employees, the reaction was clearly different. Those buyers cared about security, observability, and access control, the unglamorous infrastructure behind automation. Making that transition meant more than 1,100 customer calls in the first year, with each conversation refining what excited people and what made them nod. Early on, the team had to work hands-on with customers to get their use cases running, which gave them deep familiarity with real workflows. The moment the Australian firm’s use case worked and visibly generated savings was when the direction became obvious.

Instacart became the first real enterprise customer through a power user who was obsessed with the product. He brought Gumloop into a Slack channel, sold it internally, and taught colleagues how to use AI tools and automate tasks. The team later hired him as one of their first employees, and he helped them learn how enterprise sales works: how to deal with procurement, how to price, and how to identify a champion. That led to the next logo and the next, since people who move between companies often bring tools they love with them. The founders argue the early product was genuinely the best in its category, partly because they built from first principles without studying competitors, which produced a model that differed enough from other tools to be significantly more powerful. They note that the problems being solved are hard, which is why others did not build this way.

What enterprise readiness requires

Large companies require role-based access control, SCIM, SAML, and audit logging. These requirements follow from the stakes: a publicly traded company with sensitive data needs to ensure that thousands of users can do only what they are meant to do. Requirements can become highly granular, such as a group of 500 users who can perform ten specific actions, or an outsourced team that must have no access to data at all. Enterprises also demand their own API keys, hosting in their own cloud, audit logs for every tool, and APIs that feed that logging into their data lake. The founders acknowledge this can be frustrating, since customers initially disable functionality the team worked hard to build. The pattern is that trust builds over time, and capabilities are enabled progressively.

Discovering these needs came from hundreds of conversations. After building for a while, the team develops a sense of which requests point in the right direction and which to ignore. Most of what large companies ask for is something other large companies will want later, so it gets built. The founders emphasize that the care taken, the speed of response, and the feeling of being a partner matter as much as the features themselves.

Solving the blank page problem

A powerful, open-ended tool leaves people unsure where to begin. Gumloop’s answer has evolved from a template gallery, which grew after an early advisor pushed them to build a hundred templates instead of three, to use-case pages with prebuilt agents and case studies. The team also runs workshops where they ask companies what they would automate if they had a magic wand. Those sessions typically produce dozens of ideas, and the team helps build them, which sparks more. Some customers arrive with ten ideas and have already built half of them. Sometimes the work requires inspiring an entire team from scratch.

The company’s own use of agents

Gumloop runs on its own product. The first breakthrough internal agent, Heimdall, is connected to every data source in the company and answers questions across Slack channels. Questions like finding users who signed up in a specific time zone and role can take about twenty minutes to resolve, and that has replaced the need for a dedicated analyst for customer questions. Heimdall spawned other agents: a sales agent that automates the sales process so the team can focus on conversations with customers, and a customer success agent that tracks every account’s health score and surfaces anomalies in usage. The education lead runs cohorts every two weeks that teach hundreds of people to build agents. Much of that operation is automated, from sign-ups and follow-ups to editing the Friday demo videos, which are then distributed to customers.

Product-market fit signals

The first meaningful signal came when people spent hours building workflows on an early, clunky builder. The founders had built plenty of software nobody used, so seeing people invest five hours of an afternoon was striking. Later, they saw users spending eight to ten hours a day building automations for their own jobs or their whole team’s jobs, and some understood the platform better than the founders did. The Shopify rollout was another milestone: access went out to roughly 8,000 people in a single day, and people began building on their own without hand-holding. Shopify’s adoption was word of mouth, initiated by someone from Instacart with influence at Shopify, who put the tool on their radar. Shopify evaluated several automation tools the same week and kept the one that stuck, then invested after they saw the rollout.

Usage patterns vary widely by company. Some see concentrated use by a single team automating one function. Others see wall-to-wall deployments with light use in some teams and deep use in others. Some employees use Gumloop without realizing it, through reports and call prep running in the background. The company avoids per-seat pricing so that no one hesitates over whether they should use the tool.

Pricing as a strategic choice

Pricing has changed considerably. The company started with a $20 and a $40 monthly plan, modeled loosely on ChatGPT’s pricing, and quickly realized the plans undervalued what business customers were getting. They doubled prices three times during the batch while keeping the same plan names. Later they moved to a credit system and then to a model that is now quite different: tokens, compute, and APIs are sold at cost, with an orchestration fee added on top, similar in spirit to OpenRouter. The founders argue that transparent pricing is essential for being in the build camp. Most customers deploy in their own cloud, so the product functions as internal infrastructure, and opaque pricing would make the company the enemy. The pricing is also model-agnostic, so customers can use Claude, a direct agreement with OpenAI, an internal routing layer, or an Amazon Bedrock proxy.

Demos, fundraising, and staying lean

The founders learned that showing the product is far more persuasive than describing it. Automating work sounds like marketing in the abstract, but when people see it working they start to believe it, so they now open the product or grant access rather than lead with a pitch deck. Their first round was the only one they actively raised, through a week of meetings arranged with YC’s help. The later two rounds were preempted, because they kept building without a deck and did not need the money. The founders believe that is what made investors want in: showing that the company changes how people work and has real market impact matters more than gaming an investor with a polished pitch.

The company originally planned to be a ten-person billion-dollar company, a plan announced when the Series A was raised with only two co-founders and two interns. Enterprise sales quickly revealed how much support large customers need, and the team has grown to roughly 45 to 50 people. They still aim to stay lean, but the metric they now optimize is the multiplier between how large customers think the company is and how large it actually is. They see the eleventh person as adding substantial value, and they believe being too small can hamstring them.

Where the company is headed

The biggest constraint is awareness: many prospects hear about the company through a friend or inbound channels and are surprised by how much the tool can do. The second is capacity. The company has a long list of customer requests it could be building, and it hires carefully, slower than the average company, for engineers, designers, AEs, and customer success.

The central thesis is that the people who understand a task should be the ones automating it. The anti-pattern the founders see is a marketing operations team facing a tedious, revenue-draining process that writes a spec for an engineering team or a consultant, then cycles through imperfect feedback meetings to get something half-baked. Now anyone can build an agent, so the real blockers are access to the right data, permissions, and approval. That is why the company builds first for IT teams: once they give the green light, anyone can automate hundreds of hours of work. Leadership determines how quickly this happens. A company like Shopify clears the way, while a large European health tech company may have an IT department that says no to everything.

The founders explicitly reject the framing that AI means fewer people. They describe a future in which everyone oversees agents, and in which existing people can do far more. Their eight core engineers, including the founders, collectively do the work of about five times that many people using agents.

The hard problems at the application layer

The hardest challenges sit where the labs are also working: getting the most out of current models, enabling long-running tasks that take hours, and letting agents use computers and browsers efficiently. Every feature that customers request comes with a hundred underlying problems. Browser automation, for example, raises questions about which websites are off-limits, how to prevent nefarious actions, how to review thousands of session recordings, how to understand what agents are doing in aggregate, and how to control costs. The team argues that deploying in a company requires thinking about the whole picture, with many small edges that demand strong engineers.

Staying neutral among the labs

Customers often already have relationships with model labs, and some labs now offer competing products. Gumloop positions itself as a neutral layer, a kind of Switzerland. Customers can run inference from any provider and switch when a better model appears, without being locked into one vendor. The founders point to the leverage this creates: when a provider pushes an eight-figure contract, a company using Gumloop can credibly walk away. Ownership is central to the argument. Because agents deploy in the customer’s cloud, the customer owns the database storing traces, the full integration stack, and the agents themselves. The founders expect the model layer to commoditize and labs to pursue revenue from their customers’ businesses, a dynamic several customers have already experienced when labs launched direct competitors.

Model choice also matters for cost and quality. Some tasks, such as briefing a CEO on a growth function for a board deck, warrant the most capable model available. A support workload running 80,000 times an hour may be better served by the cheapest adequate model. Admins can enforce model choices by team or use case, which the founders find produces a better experience for everyone: it is cheaper and faster for end users and more efficient for the company, rather than having every employee default to frontier models without limits.

Buying dynamics and adoption

Buying tends to be a riddle that varies case by case, but a pattern is emerging. The person who surfaces the tool and gets most excited is typically an IT leader responsible for the AI rollout and security, facing a situation where everyone uses dozens of tools and data flows everywhere. Those leaders tend to light up when they see the feature set, and they unblock sales and customer success teams by granting access to internal data. Adoption often starts with an individual who found the product on Twitter or LinkedIn, then moves up through their manager. In one example, a pilot with a small sales team generated three times more revenue in a week than the same team had in the prior three months.

The founders are still learning how to run pilots without reaching the decision maker. A pilot without access to the tools people actually need is not very helpful, and the number of connections available correlates directly with how good the experience is. Collaboration is a key differentiator here. Gumloop allows agents to be shared, with several people talking to the same agent, and lets users see how a coworker doing the exact same job interacts with an agent in a public Slack channel. Seeing peers use agents naturally pulls others into the practice.

Moving to San Francisco and the founders’ motivation

The move to San Francisco gave the team validation that mattered. Before, they were two people with laptops saying they automated work, and no one cared. Afterward, people took their calls, and the move provided guidance for turning that momentum into something larger. Still, the founders believe founders in Canada can build generational companies. The company keeps offices and employs many Canadians, and they expect to return to Canada at some point. Hiring in Vancouver, Toronto, and Montreal is a viable advantage, since the talent is there.

Asked what drives them, the co-founder Max described a fear of mediocrity, a terror of looking back in thirty years and realizing an opportunity was wasted. His experience at Amazon crystallized it: a job at a big tech company looked like a secure life, but within a week he could not imagine staying, because the pace was slow. Building with a team of ten, he felt he could ship in a weekend what took the larger organization far longer. That is the environment he wants: fast-moving, shipping quickly, and close to the frontier.

Share post

Stay In The Loop! Subscribe to Our Newsletter.

Get updates straight to your inbox. No spam, just useful content.

Recommended for You

CAN CHINA BEAT WAYMO?

CAN CHINA BEAT WAYMO?

This episode discusses three critical topics in AI: the true nature of recent AI agent "breakouts," arguing they highlight governance and security flaws rather than model danger; the role of AGI narratives in fueling the current AI investment bubble and questioning its sustainability; and China's aggressive strategy in the global robotaxi market, potentially outpacing Western counterparts like Waymo.

Your agents lack context: Here's how to fix "You're absolutely right!" — Brandon Waselnuk, Unblocked

Your agents lack context: Here's how to fix "You're absolutely right!" — Brandon Waselnuk, Unblocked

Brandon Waselnuk of Unblocked discusses the critical need for robust context engines in AI-driven software development. He explains how AI agents' lack of company-specific understanding leads to compounding costs like wasted tokens and rework. Waselnuk outlines common pitfalls in providing context and details six essential characteristics of an effective context engine, demonstrating its impact with a 50% token reduction and significant time savings. He also introduces three open-source tools from Unblocked, including a workshop to build a relational context engine, emphasizing that "access to information is not understanding" and that context, not intelligence, is the current bottleneck for AI effectiveness.