For two decades I've turned emerging technology into products people use every day, in both consumer and enterprise. I've led teams, and I still build by hand. I make powerful tools simple, trustworthy, and approachable for everyone. The dozen-plus tools and agents below are a snapshot of what I built to learn, mostly for myself, over the last five months at South Park Commons. It's changed how I work, and shaped what I want to build next.
17 years at Google repeatedly building 0-to-1 AI and productivity products, including Inbox by Gmail, Gemini for Workspace, and a conversational-AI product at Area 120 that Google Cloud AI acquired. Then VP of Product for AI and Search at Slack. Now Founder in Residence at South Park Commons. MIT EECS.
Some of how I build hasn't changed. I've always run experiments and killed most of them. What's different now is speed. I can get an idea working in an afternoon, so I try far more things and drop the ones that aren't panning out without agonizing over it. The skill that still matters is taste, knowing when something's worth pushing on and when to walk away. I talk to the people who'd use a thing more than I used to, because that's what keeps me on the real problem. And I spend more time on my own workflow, because the leverage now is huge.
A few things stay constant. I want what I build to be powerful, simple, and safe at the same time, and I don't like trading one away for another. Access stays scoped to what an agent actually needs, and I don't merge anything without a security and architecture pass.
Mara is a Slack agent I built for myself and use every day. I started with the obvious features, a morning digest, drafting in my voice, tracking, search, and they all worked. But the one I keep reaching for is the simplest. It answers real questions about my work the way someone who knows me well would, because it runs on my own data. I've built four assistants in Slack. Mara is the one I actually use.
What I took away: personalization is what makes an assistant feel like yours instead of generic, and that comes from grounding it in your own data and how you work. Where it lives decides whether you actually use it. And a proactive feature only earns its place if it's right almost every time; if it isn't, it's just noise.
My Drive is where I keep everything that matters, but an agent I point at it shouldn't get to see all of it. Clio is an MCP server that gives each agent only the folders and files it should touch. I built it out into a small system. One skill keeps my Product Ideas doc up to date, another maintains my Product Briefs as they change, so those docs stay current on their own. My Hermes agent is next, on the same short leash.
What I took away: we're all about to be running lots of agents, and all-or-nothing access won't hold up. Today's OAuth wasn't built for this. The platforms will probably fix it eventually; until they do, the hard problem is giving an agent real power over your data without handing it the keys to everything. Good UX helps, but this is really a safety problem.
I take a lot of meetings with people I haven't met. Prepping used to be manual. I'd have to remember to ask Gemini Deep Research hours ahead, write a long prompt, then dig the result back out of my chat history. Now a scheduled task handles it. For any meeting worth prepping, it drops a shadow event on my calendar with a short summary and a link to a full Notion brief, grounded in my email, calendar, Slack, notes, and the web, and refreshed with anything recent. It's sitting on my phone, where I'd be looking anyway.
What I took away: the value is in the closed loop. I don't ask, wait, or go hunting; the prep just shows up. That's a system rather than a tool, and the difference is something I keep coming back to. It also taught me you don't always need new UI. Often the bigger win is quietly delivering value inside the tools people already use.
Agents write long plans for us to review, but right now you hand the feedback back by dumping it into one chat box. Commenting on a document section by section is an older, better way to review; it's why doc comments exist in the first place. So I built a skill where Claude Code drafts a plan as a Notion doc, then works through my comments until it's final and becomes the spec it builds from. It worked well enough that I extended it to web-based AI too. This very page came together the same way, through comments left straight on the live Vercel preview.
What I took away: reviewing work belongs somewhere built for it, not in a terminal. People and agents are going to keep working on the same documents, and making that safe and actually usable needs the right interfaces and real account identities.
I schedule a lot of meetings, and I like to customize my availability, which means flipping between calendar and email. Markfree is a Chrome extension that turns that into one step. You click your free slots on Google Calendar, then copy and paste. It's simple and free, which made it a good thing to practice launching on. The launch itself was the real lesson: store approval, a business address and phone that weren't my own, a demo video. I stopped short of full go-to-market.
What I took away: the last mile took several times longer than the build, and this was a simple product. Now I know what "shipped" actually costs, and that's what tells me whether something's worth taking all the way or just keeping for myself.
I kept hitting the same wall. Coding agents are weak at design, and they redo it from scratch every pass instead of holding onto a system. I first tried a full design companion, a Lovable-style UI wired into Claude Code, but matching that quality needed training data I didn't have. So I narrowed it to a Claude Code skill that sets a design system up front, holds the app to it, and grows the system as the app needs new pieces, the way a designer would. It worked well enough that I open-sourced it, free for anyone to use. (Built Feb '26. Then the Claude Design skill and app happened 🙂)
What I took away: design is its own language, and it isn't native to how agents build, so you have to hand it to them as a guardrail. What worries me now is that as skills multiply and the tools change weekly, overlapping ones will start causing failures that are hard to trace.
Often the thing standing between you and value from AI is just remembering to ask. So I wondered what would happen if an agent lived inside your to-do list and quietly helped things get done, with no prompting. I built it, extended it into meeting prep and email triage, then shelved it. The real power needed write access, and today's OAuth is all-or-nothing, so it was read-only or nothing. As my first solo build, I wasn't ready to be the steward of that much of someone's data at that scope. But the meeting-prep piece was good enough that it turned into the system I use now.
What I took away: a lot of what didn't work was UX I hadn't nailed (session-based versus chat, and meeting people where they already are). And safety and cost weren't things I could bolt on at the end; they shaped the whole thing. I'll bring pieces of it back.
And a long tail of other experiments. A sampling:
A demo is easy. An agent that safely and reliably does what you intend is hard. So is everything around it. It has to earn enough trust that you'd hand it real work. It has to meet people where they already are. And it has to work for the person using it and the agents acting on their behalf at once.
Powerful software in everyone's hands could do enormous good, and it could also do real harm. I'm an optimist, and I love building things people actually use, but I don't take the risks lightly, and that shapes how I build. Now I want to take what I learned and put it into a product I can scale to millions.