Rethinking how a small business works with AI Agents
Chipp is a startup building AI agents for small businesses, without code. The technology worked. The problem was that it asked people to think like engineers, in agents, prompts, and pipelines, when the people using it were dentists, coaches, and shop owners. I joined the team to rethink the product from the outside in, starting not from what the technology could do, but from how people already understand work: as something you hand to someone you trust.
AI was still considered an early technology when the original product was developed. The product could handle an enormous range of scenarios, and every one of them arrived as another feature, another setting, another concept to learn. The challenge wasn't adding capability. It was finding a way in. Small business owners don't have time to become AI operators. They have a business to run. So the real question became: what would make this feel obvious to someone who is not familiar with AI technology?
After talking with a couple of small business owners and operators in North America, one thing became clear. They weren't looking for tools to configure. They were looking for help, the kind you hire other people for. The mental model they already had wasn't a pipeline of agents. It was a team. So we stopped figuring out how to make a better agent builder and started building a company. You don't configure a bot. You hire a team.
Before touching any screens, I set out what the experience needed to be. Four principles guided every decision that followed.
Powerful, yet simple. Chipp should stay a powerful tool, not a simplified one. The goal was to make complexity feel intuitive and approachable, not to remove it.
Designed for a continuous journey. Not a one-time setup tool. Build, train, learn, improve. The team grows with the business over time.
More of a human language. Clear, human, action-oriented communication throughout, and an opportunity to stand apart from everything else in the category.
A guided experience. Start by understanding what the user is trying to do, suggest paths, and help them move step by step toward an outcome.
If business owners and operators already understand teams, the product should behave like one. A General Manager sits at the top, giving a briefing on how the business is doing. Under that are Teams, each led by a Director. Under each Director are Specialists who each do one job well. The owner manages up, not down. You talk to Directors. Directors handle Specialists. Nobody talks to a Specialist directly, the same way you wouldn't reach past a team lead in a real company. Every word in the product follows this. Director, Specialist, hire, brief, team. Never agent, pipeline, or orchestrator. Language does a lot of the design work here.
Each team is made of Specialists, and each Specialist does one job well. Underneath, a Specialist is not a single agent. It's one or several agents working together to handle that job. Most people never need to see that. They see someone who answers the phones, not the pipeline that makes it possible. But the agents are still there, reachable for anyone who wants to go deeper. Power users can drill down and manage them directly, buried far enough in the interface that it never gets in the way of everyone else.
Prompting is a technical behavior. It asks people to learn how to communicate with a system. If this is a team, the interaction should resemble how people already work with each other.
The Director chat became the primary interface, but the moment that makes the metaphor real is being able to call your team. Not open a config panel. Call them, the way you would call a colleague who handles something for you.
Small behaviors like this carry more weight than features. They're what turn a metaphor into something people believe.
The process started as sketches and in Figma. That's where thinking happens for me, loose, fast, and without commitment. But instead of carrying those ideas all the way through as static screens, I moved them into working prototypes in Claude Code as soon as they were worth trying. What emerged was a back and forth. Sketch an idea, build it, see it working, learn something the static version couldn't tell me, then return to Figma to think it through again. Each tool did what it's best at. Figma for exploring and deciding, code for feeling whether the decision was right. Claude brought my thinking to life fast enough that I could test whether it was any good, and that speed boosted the creative process.
I created DESIGN.md and BRAND.md in Claude Code, two files that became the binding source of truth for the product. Tokens, components, spacing, motion, voice, all in one place. If a Figma frame or a library default disagreed with them, the documents won. Putting it together as documents rather than a component library meant it worked where the team already worked: in code, readable by both people and AI.
Because DESIGN.md and BRAND.md were written to be read by Claude Code, it was faster to generate other pages and have them come out on-brand. The marketing pages were built this way, aligned to the product without a designer in the loop for every screen. That felt like the real outcome. Not a set of files, but a system the team could keep building with after I left.
AI has the same problem every new technology has. It arrives speaking its own language and asks people to learn it. Making it human means going back to something older and simpler: how people already understand work, trust, and help. This project was an exercise in exactly that. Not making AI smarter, but making it something a human could recognize.
I joined Chipp as the first and only designer, brought in as a contractor, working directly with the founders to rethink the whole product from the ground up. Along the way, I prototyped the flows, developed a new visual design direction, and provided the documentation the team needed for development.