Principles for Building Effective Vertical AI Products

The promise of vertical AI is easy to state and hard to deliver. The workflows that win in a domain live in the heads and habits of its best practitioners. Vertical AI takes those workflows and codifies them into agentic systems that deliver capability, quality, and efficiency a third-party frontier model can't match.

The trick is finding those workflows and translating them into the product, which in an AI-native company is the context layer, the agentic harness, the data systems and the feedback loops that drive continuous improvement. At Monaco, we build for the best sales teams, and we have world-class go-to-market experts in-house.

Seamless translation doesn't happen just because great engineers and great sales people work at the same company. It takes an organization and a culture that bring world-class GTM and world-class engineering to the same table every day, speaking a common language and rapidly building based on that shared vernacular and best practices.

We've done this translation many times at Monaco and settled on a set of principles that work for us. We think they apply to any vertical AI company.

1. Make product observability a first-class citizen

Agent traces are the lifeline of any AI native company. Every interaction between a user and our product is appropriately traced in Braintrust and Judgment Labs, and everyone at Monaco (engineers and non-engineers) can read those traces.

For engineers, traces are a granular debugging tool: which tool call failed, what context the model saw, where the reasoning went wrong. For our GTM team, they're a way to ground the product in our sales use-cases. Team members can see that an email outbound didn't generate correctly, but without the trace they can't see why. Was it the research step, the prompt, or a missing signal about the account?

Once traces are open, domain experts can diagnose product behaviors at a level of detail not previously possible. They answer their own questions without waiting on an engineer. They also catch problems engineers would never notice, because they know what a good answer looks like. In vertical AI, observability isn't just an engineering concern. It's how your experts learn the system well enough to improve it.

2. Universal tool access

At many companies, engineers get frontier models and agentic tooling while everyone else gets ChatGPT. For a vertical AI company that's backwards. The people with the deepest domain knowledge should have the most powerful tools to express it. So every Monaco employee gets access to frontier models. In practice our domain experts are among the most aggressive token users.

The MCP server that exposes our agent harness and tools is also open to the whole team. When a seller pulls an account, builds an audience or drafts a sequence through it, they're using the same tools our self-driving agents use. That is the core of agentic product dogfooding: not "does the UI work?" but "does this tool give an agent what it needs?"

The same goes for prompts. Our domain experts don't just give feedback on prompts but are actively told to change them. That's why we invested in a user-friendly prompt management platform in Braintrust rather than keeping prompts in code only engineers can touch. A sales person can open a prompt, edit it, test it and see the difference without waiting on an engineer or a deploy.

3. Meet people where they already work

The fastest way to lose non-technical teammates is to ask them to do their work in a foreign interface or UI. So our internal AI with full access to our platform lives in Slack where everyone already is.

HAL, our in-house Swiss army knife agent, started life as an AI SRE bot. It now also handles product triage and customer success questions. Anyone can tag it in a thread or DM it. An engineer asks it to investigate an alert. A sales team member asks how a feature behaves for a specific customer. Both get answers grounded in the latest code, from the same agent, with the same data access.

There's no separate engineering tool and GTM tool with different views of the truth. Unified interfaces for doing work increase our throughput in shipping customer-focused improvements because product needs get communicated and implemented as soon as they are mentioned.

4. Bidirectional enablement seeds product ideas

Enablement usually means product teaching sales how to sell the new feature. We run it in both directions.

• Pull. GTM team members sit in every product meeting. They pull the roadmap toward what customers actually need, in real time, not in a quarterly planning doc.
• Push. Every two weeks we run hands-on sessions showing the team how to use the latest releases, models and features.

Bidirectional collaboration is crucial for seeding new product ideas. We host periodic agents hackathons where teams are composed of both GTM team members and engineers. For example in one hackathon, our engineering and GTM teams worked side by side and shipped 23 sales-focused agentic workflows into the product in 4 hours. Sales team members brought the workflows and the judgment about what good looks like. Engineers brought the understanding of the harness. Neither side could have built those workflows alone in an afternoon.

5. Your best domain experts are builders

The most consequential choice we made was to treat our strongest GTM people as builders, not just stakeholders. They don't hand requirements to product. They sit inside it, leading our work on agents. As one concrete example, our head of agentic deployment was a GTM lead and one of our best sellers.

His team spends their time on the work that decides whether a sales product surface area is any good:

• Creating agents and defining the workflows and skills they run
• Annotating data so the product learns from what a great seller would actually do
• Guiding the agent roadmap
• Serving as the team's lens into how GTM really works

It can feel expensive to pull top performers away from quota-carrying work. But in a vertical AI company, an expert's judgment is worth far more encoded in the product, where it runs for every customer, than applied to a single customer segment.

6. Experts own the evals

If domain expertise is what makes a vertical AI product better, then domain experts should decide what "better" means. In many AI teams, engineers write the evals and guess at what good output looks like. We'd rather our evals reflect how a top seller judges an email, a call plan or an account brief.

So our experts define the rubrics, label the examples and name the failure modes.

In the agentic software analogy, today tests are the source of truth about a product not the code itself. Similarly in vertical AI, whoever writes the evals decides what the product becomes.

Enter the Flywheel

These principles reinforce each other. Open traces let experts understand the system. Shared tools let them act on what they learn. A common interface keeps everyone looking at the same truth. Two-way enablement seeds product ideas. Expert builders and expert-owned evals close the loop.

The result is a flywheel. The better our GTM team understands the product, the better they make it and further the better it gets, the more of their expertise it can absorb.

This approach has worked for us and we believe the same model can be applied to AI-native companies in any domain.

If building the future of sales sounds like your jam, join us!