Gusto Cofounder Automates Recurring Small-Business Work Through SMS and Slack

Edward Kim describes Gusto Cofounder as an AI product for small businesses that can automate “most of the business processes” they already handle through Gusto: running payroll, approving time off, reminding employees to submit timesheets, and other recurring back-office tasks. The product is also meant to work outside Gusto’s existing functions. Kim’s example is a tour-guide business that needs to know if it will rain, alert the owner, and email the day’s customers to bring an umbrella.

The product starts from Kim’s view that most people still use AI as “a glorified search engine.” Even more advanced users, he said, tend to ask for research, summaries, reports, or drafting help. They begin with an intent and expect a response. The “agentic” promise — software that does work on the user’s behalf — has reached technically creative users, but Kim argued that the “remaining 99.9%” are mostly still in question-and-answer mode.

That diagnosis shaped the product. Gusto Cofounder does not begin as an open-ended AI canvas, because Kim thinks open-endedness creates what he calls the “blank canvas problem.” Instead, it begins from what Gusto already knows customers do repeatedly: payroll, HR, time, scheduling, approvals, and timesheet collection. From there, it suggests ways to automate those routines end to end, including cases where the owner does not need to log into Gusto at all.

The interface examples shown for Cofounder put that argument into product form: “Meet your new Cofounder,” “I get your business,” “I catch what you miss,” and “Your to-do list, tackled — from anywhere.” The examples include running payroll from SMS or Slack, flagging payroll deviations, auto-reviewing time-off requests, setting up onboarding monitors, requesting approval for expenses over a threshold, generating weekly labor-cost reports by department, and summarizing online reviews. One payroll flow is reduced to a text exchange: the owner asks to run payroll, Cofounder replies that it is ready, shows payroll details, and the owner approves by text.

Kim’s point is not that small-business owners need a more powerful generic chatbot. It is that the AI has to be connected to actual business processes, use what Gusto already knows customers do, and trigger work in channels owners already use.

Harj Taggar framed the product against Gusto’s scale, saying in his introduction that the company recently crossed $1 billion in annual revenue, serves more than 500,000 small businesses in the United States, and counts one in five new businesses started today as customers. He asked what it looks like to create a new AI product inside a company already operating at that scale. Kim’s answer began outside the company roadmap: he had set up what the transcript calls “open claw” himself.

The setup was not trivial. Kim said he spent about eight hours getting it working, bought a Mac Mini, installed the software, and air-gapped it because he had heard stories about AI agents deleting people’s emails. The result, he said, was something “only an engineer could really do.” After all that work, he still found himself mostly using it like a search engine.

But one part of the experience changed his view: texting the agent through Telegram. Reading that this was possible had not done much for him. Using it did. Kim said the experience of texting an AI agent was far better than opening a browser and logging into Claude or ChatGPT. Taggar said he had the same experience and argued that people underestimate chat as the interface. His own instinct as an engineer had been to add more client functionality — project-management views, more UI — but AI changed the priority: make the agent smarter so the user can do what they want from Telegram rather than needing a more elaborate interface.

Kim tied that lesson to a broader point for technical leaders. Reading about a tool and actually setting it up are not equivalent. “If you’re a technical leader, you should be coding,” he said; and if not coding, at least installing and using the new tools directly. The gap between reading about the open-source agent and experiencing it firsthand was large enough to generate the product idea.

The first working prototype came during a missed flight. Returning from vacation in Madrid, Kim missed the London-to-San Francisco leg of his trip and suddenly had five uninterrupted hours in an airport lounge. He had been using Claude Code and was “blown away” by the ability to describe an intent and have code built from it. That led to the question: why should customers wait for Gusto’s roadmap if they could tell Gusto what they wanted and have Gusto build it for them?

In those five hours, Kim built a prototype. The first version was not the current Cofounder. It was a chat prompt that generated Gusto-looking CRUD web apps. A customer could ask for a survey form for employees, a to-do tracker, or a CRM, and the prototype would build a web app using Gusto’s design system so it looked like something Gusto had produced. Technically, Kim said, it wrote code, saved it in a database column, and executed that code when the page was visited. It could store data, but the customer had to bring that data in; it did not yet make meaningful use of what Gusto already knew.

That limitation became the turning point. Taggar framed Gusto’s position as a potential advantage because it already has business context, using the phrase now often applied to companies that serve as a “system of record.” Kim agreed. The prototype was interesting, but it did not leverage Gusto’s aggregate data about what businesses in different industries tend to do, nor each customer’s own behavior inside Gusto. The idea shifted from “build any web app” to “use a prompt plus Gusto’s data to build an automation for a business process the customer repeats every week.”

That became the core model for Gusto Cofounder: each customer can have many automations, and those automations run on triggers. Kim said one technical inspiration came directly from reading the source code for the open-source agent he had been using. Its heartbeat, as he described it, was “surprisingly simple”: a cron job that runs an LLM every 30 minutes. Gusto Cofounder borrowed that idea, but not blindly.

For tasks such as payroll, a probabilistic heartbeat is not enough. Taggar said his own setup often required deterministic cron scripts outside the gateway because a heartbeat might probably fire in the morning but not at an exact guaranteed time. Kim agreed and said Gusto Cofounder added multiple ways to trigger a job, including ordinary scheduled cron jobs. Kim said Cofounder will detect whether the thing a customer is asking for is better suited to a regular cron schedule than to running a prompt every 30 minutes, which he also noted can become expensive.

Kim said Gusto’s customer base gives the product a clear path into daily operations. Small businesses may not talk in enterprise AI terms — workflows, token budgets, and automation architecture — but they understand recurring work that eats an hour every week.

His example was a massage spa that runs payroll through a sequence of manual steps before it ever gets to Gusto. The business exports data from Mindbody, moves it into Google Sheets, performs calculations to translate that data into commission, tips, hours, and related payroll inputs, and only then enters the result into Gusto to run payroll. The final payroll step is simple. The “work before the work” is what consumes time.

For that customer, Kim said, Cofounder’s value does not require an abstract pitch about AI. The owner already has the task on the calendar. If Gusto Cofounder can handle the recurring preparation and then text a summary for final approval over SMS or Slack, the product is immediately understandable: say yes or no and move on.

The adoption dynamic also differs from enterprise automation. In a large company, automation may create resistance from employees worried about what it means for their jobs. In a small business, the recurring manual work is often work the owner does not want to do in the first place: exporting data from one system, manipulating it in another, and re-entering it elsewhere. Kim agreed with that contrast. Small-business owners, he said, want “to do more with less.” He compared them to founders: entrepreneurial, scrappy, and eager to save time if it lets them spend more of it building the business.

Kim framed Cofounder’s initial value as freeing owners to focus on growth, products, strategy, and expansion. But he said the name “Cofounder” reflects a broader ambition than business-process automation. The second step is proactive advice and action: telling a business about things it is not doing but should be doing.

The examples range from compliance tasks to tax credits. Kim described a case where Cofounder might identify that a company appears to be doing qualified research, inform the owner that an R&D tax credit may be available, fill out the forms, and ask for review and missing information. He said this was not hypothetical: he attributed to Gusto the discovery of $50,000 in R&D tax credits for Cabana Pools, which he said the company did not know were possible.

Taggar connected that to his own experience building software for eBay power sellers. Only a small, technically sophisticated sliver of sellers used tools to automate listings or constantly check competitive pricing. He suggested Gusto could now give similar market intelligence to ordinary small businesses: what to sell, how to price, how to optimize. Kim said he had already seen an automation where a business asked Cofounder to look at competitors every week, generate a report, and suggest how to stay ahead. He described that as an example of the more proactive business partner Cofounder could become.

Kim said Gusto had “just launched” Cofounder and added 500 customers. Before that, the company had given early access to a “Small Business Council” of about 20 customers. The strongest early reaction, he said, was to the ability to run Gusto work through text message.

Kim compared the customer reaction to his own reaction to Telegram with the open-source agent he had set up. Once a customer provided a phone number, entered an eight-digit code, and could run payroll or contractor payments by text, the accessibility of the workflow became obvious. The product made it possible to do these tasks “anywhere I’m at,” as Kim summarized the feedback.

But the more surprising usage was not payroll, time approvals, or expense approvals. Those were expected. Kim said many automations customers created had little to do with Gusto’s existing product. The weather-and-tour-business example was one: text every morning if it is going to rain, check a customer list in an Excel file, and email the day’s customers to bring an umbrella. Kim said that has “nothing to do with what Gusto does for them at all,” but is “absolutely possible” and, in his early-customer account, what people are doing with Cofounder.

That breadth shapes the roadmap. Today, Kim said, Cofounder supports SMS and Slack. He wants to add Telegram and WhatsApp, partly because SMS has character-count constraints and partly because many businesses already operate through those messaging channels. He also wants more connectors. Current examples include QuickBooks, Notion, and Google Workspace, but Kim expects many vertical-specific integrations. He mentioned a dental practice using Curve Dental and asked why Cofounder should not be able to move information in and out of that system.

The product team is not claiming to know exactly how customers will use the system. Kim said Gusto is in a mode of observing what people do and letting customer behavior guide the roadmap.

A further expansion would move Cofounder earlier in the business lifecycle. Today, a user has to be a payroll administrator for a company on Gusto. Kim said the data models were built so that does not have to remain true. A future version could be used by someone who does not yet have an EIN, someone considering starting a company, or someone with a side hustle. At some point, that person might ask Cofounder to help get an EIN or register as an employer in California. Kim said Gusto already has those capabilities as a company.

For Kim, the more “mind-blowing” part of Cofounder was not only what was built but how it was built. The product started with his airport prototype, then he showed it to engineers and designers and “organically roped” them into the work. The version the team launched was built by five people over 10 weeks: four engineers and one designer, with Kim as one of the five. He said they went from a whiteboarding session to a full “tier one” company launch in that time.

He does not think that would have been possible without AI. One striking change was role fluidity. Kim said he had not coded in many years, but AI changed what he could contribute. The designer contributed as much code as any engineer, including production-grade code. Engineers prototyped UI without waiting for polished design work, and the designer used Claude Code to refine and improve it. When the designer wanted functionality, she wrote code, and engineers helped take it the rest of the way. Kim described this as designers moving into engineering and engineers moving into design. The shared responsibility became writing and committing code.

Kim’s advice for larger companies trying to regain product velocity centers less on what the team added than what it removed. For this zero-to-one project, he said, there were no meetings, no tech specs, no Figma files, no docs, no Jira board, no sprint planning, and no retrospectives. He explicitly limited the lesson: he would not recommend that model for every part of an organization. But for this type of product exploration the team used only two persistent pieces of infrastructure: a 24/7 Zoom room that people could enter and leave, and Claude Code with “lots of Claude Code tokens.”

That did not mean the work left no record. Taggar noted that Claude Code transcripts effectively documented thinking and direction. Kim added that the team also threw away a lot of code. Instead of discussing an idea in advance or writing a document about it, someone could open a pull request, show it in the shared Zoom, and ask what the group thought. If the team decided it was wrong, they deleted it.

Kim argued that even a 50% hit rate can be faster than creating a PRD, making Figma designs, getting approvals, and then building. In an AI-assisted workflow, trying an idea three different ways and choosing one can cost less time than aligning on the abstract plan.

That does not mean Kim thinks teams should ship every idea AI makes cheap to build. Taggar raised an internal YC debate: if AI makes code cheap, should teams build 10 things at once because they can, or should they still focus on one or two things done well? Kim’s answer was that product discipline becomes more important, not less. Teams now have more things to say no to. The abundance of possible features makes restraint harder.

Where Kim thinks AI changes the process is in how teams reach that disciplined product set. Rather than making all decisions from requirements documents, UX research, or meetings, he thinks teams should implement more permutations and debate the concrete result. Talking about a product in the abstract loses information. The implementation itself is an input.

Customer research still matters in that model. Taggar said there is information humans get from high-bandwidth one-on-one conversations with customers and from watching them use something that Claude does not yet replace. Kim agreed.

Kim sees Cofounder as part of a longer trend: over the past 15 years, starting a small business has become easier, and Gusto has contributed by simplifying back-office functions such as payroll. But even when those processes became easier, they remained work. Compliance, benefits setup, HR rules, payroll preparation, and business administration still consumed attention.

AI, in Kim’s view, makes that trend discontinuous: “a step function easier” to start and run a business. If AI can automate many of those administrative and compliance processes, owners can spend more time building products, getting customers, and growing. He said Gusto is seeing more people treat business formation as a viable path, and pointed broadly to census data on the number of business applications the government is receiving. He did not give a specific figure.

Taggar framed the same shift from the consumer side: more people starting businesses means more goods and services to choose from. Kim closed on the local texture of that claim. He said he loves small businesses because they make communities more interesting — the “random and quirky businesses” visible walking down Third Street in Dogpatch.