We Built Our Own Agent-native Tool. It Overhauled How We Build Software.

Stella Garber cofounded Hoop, an AI agent to help subcriber brands cut churn, after years at Trello watching what makes software stick. When her team’s customer discovery calls became a mess of scattered notes and competing interpretations, they built an internal AI analysis tool from scratch using Every’s agent-native architecture philosophy. It reshaped how they build their actual product. Plus: While you’re waiting for Fable 5 to return, we’ve compiled 13 copy-ready prompts based on the Every team’s workflows. Use them to plan, build, research, verify, and hand off complex work that runs for hours.—Kate Lee

---

It was Monday morning, and my cofounder Brian was reading from our agent’s weekly analysis of customer discovery calls. “Subscription retention,” he said. “Five separate brands mentioned it as their top priority, and none of them trust existing AI tools to touch it.”

Just weeks ago, unearthing an insight like this would’ve been nearly impossible.

At my pre-product-market fit startup, we’d all been speaking with prospects and trying to figure out the positioning for our product, but keeping track of everything we learned was a mess across founders, platforms, and mediums. To share what we learned during our Monday meeting, Brian would read notes in Slack, collect transcripts from Granola, and try to make sense of it all in Claude Code.

We couldn’t afford to be that disorganized. We’d recently launched Hoop, an agent that helps subscription brands reduce churn, and we needed to learn as quickly as we could. So we had to talk to as many potential customers as possible, then rigorously document and score each call to separate polite interest from genuine demand. Everyone on our five-person team was putting in the effort, but each of us had our own process, our own tools, and our own interpretation of what happened on each customer call.

So my two cofounders and I—none of us with “engineer” in our title—built an internal tool to fix it. What we didn’t expect was that the tool would change how we built our actual product for customers, too.

‘I should build something for this’

Our Monday meetings were so unmethodical because the information from our client calls was in different places depending on who had taken the call and whether they had notes based on Granola or another transcription tool. We had no way to see patterns and draw conclusions about what our potential customers wanted.

Justin, my cofounder and the resident product expert, built the first version of a tool to bring those notes together in under 10 hours over a few days, fitting it in around his other priorities.

Here’s how it worked: You’d upload a Zoom transcript, the tool would run the transcript through four or five prompts, and you’d get a structured analysis scored against the PULL criteria—a framework developed at Harvard Business School to help early-stage startups find product-market fit. The tool would also pull together all the conversations with a given prospect into a summary, so you could see the full arc of a relationship instead of just a snapshot from one call. Rather than digging through notes and transcripts, the tool gave us a consolidated analysis week over week to help us see what was working and what wasn’t.

Justin set up the app using tools we hadn’t used before: Next.js framework with ShadCN components for the user interface, Supabase for the database that compiled all the notes, Claude’s API for the analysis.

For Justin, who had studied computer science but wasn’t writing much code anymore, it was an opportunity to dust off his skills and build his confidence with AI-native coding. He started by designing and building the visual interface because he is the kind of person who gets frustrated when software doesn’t look right, even if it functions. He made sure that the look and feel of the tool matched our brand, and got the components (buttons, labels, menus) looking clean before he went anywhere near the data.

Only then did he go straight to the data. He had to make sure that the tool’s analysis of the customer conversations was better than what people were already producing on their own with Claude. Otherwise, we would never convince the whole team to use the same tool. So he created a prompt that he tweaked after manually reviewing the output several times and relying on Anthropic’s prompting best practices for Claude.

Still too much friction

The first version of the tool generated high-quality analysis, but too many parts of the process were still manual. You had to download the call transcript from Zoom, upload it manually to the tool, fill in the customer name and call type, and wait several minutes while it was processed. Then you’d create a link and share the analysis in Slack.

The team could search the transcripts and analysis in the tool, but it didn’t return good results. For example, I searched for prospects who’d had bad experiences with AI customer support tools and got no results back, even though I knew a head of customer experience had spent five minutes talking about how embarrassed they were by their AI sending off-brand responses to customers. The tool could only match the exact words in my query, not the meaning behind them.

And there was the classic adoption problem that we know all too well from our years at productivity tool Trello, where we’d previously worked. Justin’s tool was yet another place people had to remember to go, competing with Slack and Notion for our attention.

Going agent-native

Then we found the answer to our woes. Justin had been reading about agent-native architecture on Every. Instead of hard-coding a sequence of prompts that run in a fixed order, you give a model a set of tools and let it reason about how to use them. And instead of building a destination app that requires people to come to you, you bring the tool to where people already work, like Slack.

Justin gave Claude Code the link to the article and said that he wanted to build a system that aligned with those architecture principles. The agent needed two tools: one to upload and read a transcript, and one to add and edit a partner profile. With those in place, all users had to do was send a transcript to the app in Slack. The agent confirmed the partner name and call details, then uploaded the transcript, ran the analysis, created a summary page, and posted it to our user feedback channel.

Justin started checking everything he built against the agent-native architecture guidelines, not just the product-market fit tool. He’d go into planning mode with Claude Code, lay out a new feature, and send it alongside the Every article back to Claude Code and ask: “Where is this aligned, and where is it not?”

Sometimes he deviated from the guidelines when he didn’t think that users needed AI for a specific task. For example, the tool tracked LLM token usage and cost—useful information, but not something users needed to query. Exposing it to the agent would have only created confusion.

My turn in the codebase

I had a different problem. I needed to see the pipeline at a glance—who to follow up with, where each conversation stood—organized by people and stages, not just chronological call logs.

I opened Ghostty, a simple terminal app, copied the tool’s code so I could work on it locally on my laptop, and—hands a little shaky at the thought of directly editing code—fired up Claude Code.

The first thing I asked Claude Code to build was a lightweight view of the data so I could see the different stages of the pipeline at a glance. Ironically, I was asking Claude Code to build a Trello-like board of the information so I could move cards representing calls around. Old habits die hard.

I built incrementally. I noticed it’d be useful to have the status of a deal on the front of each card. so I prompted Claude Code, “Make sure each card has a one-line summary so I know at a glance where things stand.” Once deployed, deals came in with their status attached. Every time I wanted something different, I just asked.

Encouraged by Justin, I started merging code directly to the shared repo. Sometimes things broke, and nobody got in trouble, because the stakes were low and everyone treated it that way.

Brian learns agent-native at 10 p.m.

Next up was Brian, our other cofounder, who was responsible for our weekly user learnings report. Before the new tool, he would often forget and end up scrolling through Notion, or riffing from memory on whatever conversations were freshest in his mind. Our learnings skewed toward recency rather than significance, and we missed patterns that only showed up when you looked at all the calls together.

So Brian built a feature to generate the report automatically. His first version was a link on his computer that spit out a Markdown file he would paste into Notion—it worked, but only for him. His second added a Learnings tab to the tool with a button that produced the same Markdown output, but now anyone could pull a report.

That solved the access problem, but a new one surfaced. The team couldn’t tweak the format or focus of the report without asking Brian to edit the code. Brian wanted to make the prompt for the report editable so the team could tune the reports without touching code. At 9:25 p.m., Justin suggested in Slack: “You should make the prompt an editable field and pass it to the agent.”

Brian didn’t understand what that meant, so he pasted Justin’s message into Claude and asked for an explanation. Claude walked him through the agent-native architecture philosophy, and Brian started to understand: Instead of giving a human a text box to edit the prompt, you give the agent a tool that lets it read and modify the prompt itself. Then anyone can talk to the tool in Slack and tell it what to change.

By 11:15 p.m., Brian had the feature working. He tested it by telling the Slack agent to rewrite the Learnings prompt in Klingon, and sure enough, every report came out in Klingon. It took two hours, from start to finish.

More practically, a recent report flagged that four out of our last six calls mentioned the same pain point: Brands were losing subscribers who hadn’t realized they’d signed up in the first place. Customers often subscribe to unlock a discount, forget it’s recurring, and cancel in surprise when the charge lands—exactly the moment our product could step in with a savings offer or a better-fit recommendation. None of us had connected those dots individually; the pattern only emerged when the tool looked across all the calls at once.

Then something unexpected happened. Duplicate records appeared in the Learnings tab, and Brian mentioned it to the bot in Slack. The bot looked at both records, figured out one was empty, and deleted it—a “find and delete duplicates” function. He had given the agent editing rights to the database, and the model reasoned through the problem on its own. That was the moment it clicked for Brian: If you give a reasoning model simple, powerful tools, it can handle situations you never thought to code for.

What we took back to the product

The most important thing the tool did was change how we build our external-facing product. Justin took the agent-native patterns he’d tested internally and built multiple sales tools, including a helpdesk audit we can run with prospective customers to show them the value of Hoop before they sign up.

Brian went from building a Learnings tab to building something like an internal sales agent, a bot we call “Benny” that lives in Slack, taps into our sales tools, and runs tasks on command: qualifying leads, scoring them against our ideal customer profile, and updating Attio (our CRM). I went from building features for a customer relationship manager to having informed opinions about product architecture.

It also kept us honest. When every call is scored and summarized automatically, you can’t hide from what the data is telling you. When five different operators in a single week told us our pricing didn’t make sense, we had to face the facts and change it to win more deals. At a big company, a team of analysts would be writing quarterly reports off this data. We’re five people doing it weekly with a tool we built ourselves.

The tool will probably look different in another month, and that’s fine. The fluency that we’ve gained matters more: knowing when to give a model a tool versus when to hard-code a workflow, being comfortable with shipping and failing—and trying again.

---

Stella Garber is cofounder and CEO of Hoop.

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to sponsorships@every.to.