How Juries and Librarians Can Solve GTM's AI Trust Problem

How is the business doing? In Alex Bauer’s opening bedtime story, a go-to-market team sets out to answer that apparently simple question. Between the team and the answer sits a pile of business data—and a dragon. The first guardian worries about security posture. Defeating it requires paperwork rather than a sword.

The next monster has many heads, each using words differently. Its defeat requires a more consequential admission: the systems the team trusts never promised to tell the whole story individually. The team stops treating any one system as sufficient and builds a foundation underneath them, where the data can agree with itself.

At the final obstacle, the team recognizes that an unguided adventurer is the wrong starting point. Preparation matters more than genius: write down how the business works, provide a knowledgeable guide, and let adventurers teach one another so each arrival does not start from nothing. Permissions, definitions, guidance and second opinions become parts of one tool. The dragon was never the villain. The story’s happy ending is where the practical work begins.

Bauer’s company, Upside, positions itself as a data layer for agentic go-to-market. Its sequence starts with a data foundation and dashboards that establish what happened. Deep research and multi-touch attribution then address questions that were difficult to answer at scale. Making AI correct about the business, and making that data available wherever people work, allows teams to build some of the tools they previously had to buy.

Sales and marketing teams have always understood problems that engineering teams may encounter only secondhand. Historically, however, their accessible building tools were often spreadsheets and PowerPoint. Claude, in Bauer’s comparison, does for building what the bicycle did for mobility: it makes a capability accessible to more people. Bauer places himself among those newly empowered builders. Before AI, he could read and write code, but would not generally have wanted his own code in production.

An effectively unlimited supply of accomplished computer science interns changes how quickly a domain expert can iterate. Bauer compares the experience to Harry Potter discovering a magic wand. But interns building under the direction of people without engineering experience can also produce surprising results. A revenue report may be wrong while looking exactly like a correct report. The familiar hallucination problem becomes a trust problem: the person receiving the answer cannot readily distinguish success from failure.

Bauer’s practical response draws on managing people. Technical optimizations and elaborate prompting techniques may help, but he does not usually have time to pursue them. When in doubt, manage agents like humans. Give them the context and direction that would help a human team do good work.

His most portable prompting practice is commander’s intent, adapted from military doctrine: explain why the task matters. That gives an agent a purpose against which to make decisions instead of merely a sequence of instructions to obey. There is a trap in asking an agent to improve its own process, though. Bauer finds that Claude can respond by adding micromanagement. The correction is to bring it back to the purpose—the why—rather than encouraging an ever more prescriptive procedure. His website rebuild shows what useful preparation looks like in practice.

Bauer estimates that rebuilding the website at his former 600-person company would have taken two months, involving several product marketers, a designer, consulting project managers and a web team. For Upside’s rebuild, he first tried handing Claude the sources and asking it to read everything and produce the website. Even using plan mode first, that attempt failed.

The missing preparation was an explicit account of the business. Bauer maintains company-wide anchor assets, including a product capabilities reference and definitions of the people the company serves. AI helped compile the capability cards; the important work was establishing what those cards needed to contain. Each card explains what a capability does, why it matters to the defined personas, and where the supporting information came from. Citations across connected systems let Bauer trace important claims back to their sources.

That structure carries into the website: capabilities map to homepage messaging and then to product pages. The order is the mechanism:

1. Define the business reference and its structure.
2. Compile capabilities, persona relevance and supporting citations.
3. Use that organized material to guide website generation.

Define the structure before turning Claude loose. Bauer also recommends a book and an online summary for learning this approach, singling out steps five and six of the summary.

Two additional tools support review:

• De-slop skill: a general editorial cleanup pass.
• Persona bench: agents representing important customer personas, available to review material and give their opinions on demand.

The capability reference supplies the business content; these review tools help examine how that content is expressed and received.

The next example moves business context into the query workflow. Upside’s Radiant Librarian addresses a question that sounds straightforward: how much pipeline did we create in Q1? An agent can immediately assume that Q1 means January through March and that pipeline creation can be measured using a record’s created date. Both choices can misrepresent the business.

Instead, the agent consults the librarian first. Bauer describes a librarian with access to documentation, company knowledge items and information about prior failed queries and their schema. It supplies just-in-time memory before the agent commits to an interpretation. In this example, fiscal Q1 runs from February through April, and new pipeline includes only opportunities reaching stage two or later.

These definitions change what the agent should query, not merely how it should phrase the answer.

The diagram ends with the agent returning an answer with citations. The useful intervention happens upstream: company context guides the interpretation before the answer is produced. Bauer presents this through the diagram and skips the planned live demo for time.

Multi-touch attribution poses a different problem: deciding how much credit different interactions deserve for a deal. Bauer says Upside spent two years getting anywhere close to solving multi-touch attribution. During that effort, the company built an AI-native data layer that proved useful for other problems. Returning to attribution with Opus produced results he describes as impressive, although he provides no accuracy measurement. The workflow addresses questions for which there is no single empirically correct attribution answer.

For a request to attribute the Acme deal, the agent does not immediately decide the allocation itself. It initiates a jury-and-judge workflow:

1. Research independently. Separate analysts inspect the deal data and develop their own evidence-cited opinions about attribution credit.
2. Evaluate the reasoning. A consensus judge treats those opinions as inputs, not facts, and weighs the quality of their reasoning.
3. Escalate disagreement. If consensus is insufficient, the judge escalates and expands the jury.
4. Synthesize the result. The judge produces a final assessment from the analysts’ research rather than conducting a separate investigation of its own.

The separation of research from evaluation matters: the judge’s task is to assess the evidence and arguments produced by the analysts.

This is the human organizational analogy at its most concrete. When an answer requires judgment, multiple researchers and a final synthesizer can be more useful than leaving one researcher to deliberate indefinitely. Bauer applies that division of labor to agents rather than asking a single agent to become increasingly certain of its own answer.

Preparation and review still depend on an agent capable of using them. Bauer’s final example begins with the recently introduced Slackbot MCP client. Connecting Slackbot to external Model Context Protocol servers suggested a convenient route for Slack users to consult Upside’s librarian. Bauer tried it and reports that it performed poorly. That account concerns his trial at the time of the talk, not a current evaluation of every Slackbot configuration.

His explanation is economic: when AI is added to an existing subscription product, the plan’s margins may leave too little room for capable reasoning models. This is Bauer’s interpretation of the failure. His practical recommendation is to avoid weak models and inadequate agent harnesses—the environments that give models their tools and working capabilities—for important work.

Bauer calls his minimum acceptable environment tier two: a powerful model with sub-agents, plan mode, full MCP support and file editing. The model needs enough reasoning ability for the task, while the harness needs to support consultation, planning, delegation and work on artifacts. His closing warning is against handing a team only the ChatGPT web interface and expecting strong results. The environment must support the kind of work the team is asking its agents to do.