AI's blank canvas problem | Eddie Kim on building Gusto Cofounder

TL;DR An AI tool is only as useful as the first thing you point it at, and most people never work out what that is. Eddie Kim, co-founder and head of technology at Gusto, calls this the blank canvas problem, and it is the reason Gusto Cofounder exists instead of another general chat assistant. Cofounder starts from what a business already does on a schedule, running payroll every Thursday or approving time off, and offers to take it over. Four engineers and one designer built it in 10 weeks with no Figma, no standups, no JIRA, and a nine-minute median code review across 1,000 pull requests.

Watch the full conversation with Eddie Kim below.

Play this video on YouTube

Gusto started 15 years ago as ZenPayroll, a simpler way to run payroll for a small business. It expanded into benefits, HR, time tracking, and tax credits, and now serves more than 500,000 small businesses in the US. Cofounder, which launched in June 2026, is Eddie's bet that 15 years of groundwork can be handed to an agent. You tell it your business processes, it runs them on a schedule, and it checks in only when it needs a decision from you.

We sat down with Eddie for the second episode of Navigators, our series on how builders are shipping with AI, to talk through how Cofounder got built, why most AI tools stall before they do anything useful, and what happens when an agent needs to reach a system that never got an API.

What is the blank canvas problem?

The blank canvas problem is what happens when a capable AI tool arrives with no assigned job. Eddie's read on OpenClaw and Claude Code is that both hand you real capability and leave the hardest part undone, because working out what to point them at is harder than building the thing itself.

They come with all these great AI capabilities, but they don't really have any initial use case that you can use them for. It's kind of left up to the installer or the user to figure out, okay, what do I put this on? And it turns out to be a much harder thing to solve. It's not a technology problem at all.
Eddie Kim

Co-founder and Head of Technology at Gusto

Eddie hit this himself. He bought a Mac mini, installed OpenClaw, spent hours fighting the setup, and then sat there with a working agent and nothing to give it. He fell back on using it as a better search engine. That gap between capability and a starting point is why he thinks most people, even inside AI-forward San Francisco, still treat these tools as a question-and-answer box.

Gusto's answer draws on 15 years of knowing exactly what a small business does on repeat. A company with hourly employees runs payroll every Thursday to pay people on Friday. That is a known, recurring task with a known shape, so Gusto can propose the automation before the owner thinks to ask for it.

We already do all of these hard things for our customers that happen on a periodic basis. So it's very obvious that those are the first things we can solve for them, right out of the box. We kind of solve that blank canvas problem, and we even suggest to the customer, I notice you do this, what if we automate this for you?
Eddie Kim

Co-founder and Head of Technology at Gusto

How did five people ship Gusto Cofounder in 10 weeks?

The idea traces back to a missed connection at London Heathrow. Eddie had 5.5 hours to kill and used Claude Code to prototype what became Cofounder before he boarded his next flight. He showed it to a few engineers and a designer he normally kept in touch with, the group spent a week in Gusto's Denver office whiteboarding the UX and the data model, and that is the day they wrote the first line of production code. They threw the airport prototype away and started a fresh package inside Gusto's existing monolith.

What followed was deliberately process-light. No PRDs, no Figma files, no sprint planning, no retros. The team kept a Zoom room open for 10 straight weeks and most people hung out in it even while coding. Anyone with an idea for a feature wrote the pull request first, brought it into the room, and the group decided there and then whether it was worth keeping.

Eddie went back and looked up what that cadence produced. Across roughly 1,000 pull requests in those 10 weeks, the median time from opening a pull request to getting it reviewed was nine minutes, measured in DX, the engineering-analytics tool Gusto runs on its R&D org.

First and foremost, being a software developer. Writing code, opening PRs, getting it reviewed, merging it into production. We didn't write any documents. We didn't have any Figmas. We didn't have any standups. We didn't track any work in JIRA, believe it or not. No retros. The only thing we had was a perma Zoom.
Eddie Kim

Co-founder and Head of Technology at Gusto

Pull requests merged
1,000
Median code review
9min
Speak with our team

Why was the team's designer its most prolific coder?

The team's designer, Katie, had barely written code before this project. Eddie later pulled her contribution data from DX, an engineering-analytics tool, and found she ranked in the 94th percentile for pull-request contribution against every engineer in Gusto's R&D org. He asked her what made it work.

She told me there were essentially two things. One is that she'd been a little bit more technically curious, even though she wasn't a software developer. But she told me the most important thing was that anytime she'd try to write code using Claude Code, she'd get a lot of support from the engineers around her, who would actually sit down and give her feedback, tell her why this version of the code was good and why this one was bad.
Eddie Kim

Co-founder and Head of Technology at Gusto

His conclusion runs against the more automatic pitch for coding agents. What made Katie productive was the four engineers who sat down and explained why one version of the generated code was good and another was bad. The tool was table stakes. The teaching was the scarce input, and it is the part that takes real time to supply.

You just get a lot of AI slop. You actually do need to invest a little bit more in the support, have a team that's willing to spend time to teach what good code looks like. That's unfortunately not the fastest thing to do, but I think it's the most effective thing to do to help transform a company.
Eddie Kim

Co-founder and Head of Technology at Gusto

What happens when the system an agent needs has no API?

A small business does not run entirely on Gusto. Parts of it live in Mindbody, parts in Notion, parts in a Google Sheet, and stitching those systems together is usually the work a human ends up doing by hand. Cofounder reaches into them directly, and anyone who wants more can point it at their own remote MCP server. MCP coverage stops well short of the whole internet, though, and much of what a business owner depends on is reachable only through a web form.

Not everything has an MCP server. There's a lot of the world that is kind of like you can only access it through a web browser. One of the things we want to build is for Gusto Cofounder to literally open up a web browser and do the thing that you want it to do.
Eddie Kim

Co-founder and Head of Technology at Gusto

His example is sending flowers for an employee's work anniversary. There is no flowers API. What exists is a website, a checkout form, a shipping address Gusto already stores, and no vendor cooperation required to use any of it. That distance between what a business runs on and what exposes an API is the space a browser fills, and it is the gap Browserbase closes. We give agents a real browser they can drive at scale, with proxies that hold their reputation, verified access to sites that check who is asking, and a recording of every session so you can see what happened when a run fails.

Aaron Levie made the same argument from the enterprise side in the first episode of Navigators, where he called browser use the escape hatch for the long tail of software that never got an integration. Opposite ends of the market, 500,000 small businesses and the Fortune 500, land on the same missing primitive.

Will small businesses stop opening a browser to use Gusto?

Eddie's longer-term bet is that the web UI stops being the primary interface. Instead of logging in to submit a PTO request or approve a timesheet, the owner texts or Slacks Cofounder, and Cofounder comes to them when it needs a decision.

I don't think that you even see customers logging in, opening up a web browser, to use Gusto much at all. They're texting with Gusto through Gusto Cofounder, or they're Slacking it. Anytime it needs the business owner's attention, it's sending them a message proactively. That's actually exactly why we called it Gusto Cofounder.
Eddie Kim

Co-founder and Head of Technology at Gusto

There is a wrinkle in that bet, which is that Gusto's customer base skews away from the AI-native default. Eddie puts the share of small businesses reporting they use AI to grow their business at around 30%, and reads most of that as search-engine-style question answering. He also thinks resource constraints make small businesses more open to AI than their reputation suggests, since doing more with less is the whole job. What stands between them and real delegation is the same blank canvas problem, applied to a customer base rather than a single product.

The demand side supports him. Eddie points at government data on high-propensity business applications, the Census Bureau series that counts new business registrations likely to become employers, and says this year is running about 10% above last year, on a multi-decade upward trend that accelerated after Covid. There are roughly 5.5 million employers in the US and, on his count, close to tenfold more sole proprietors and side hustles behind them, all of which Gusto counts as small business and wants to serve.

Where this leaves us

Eddie's advice to anyone building an agent today is to skip the planning documents and start. You can make three mistakes, delete all that code, and get it right the fourth time inside a single day. The processes we invented over the past few decades assumed engineering time was the scarce resource worth protecting, and that assumption has stopped holding.

The more durable point is the blank canvas problem itself. Model capability keeps compounding, and an agent with no assigned job still ends up as a better search box. The products that win will be the ones that already know what their users do every week and can offer to take it over. For the part of that work that lives outside any API, in a browser tab on some vendor's site that was never built with an agent in mind, that is the layer we run. If you are building an agent that needs to reach those parts of the web, you can create your first session in a couple of minutes.