Scout

Scout turns live customer conversations into evidence-backed business maps, lets humans approve the truth, then gives Codex trusted context to build the right software.

Comment

Inspiration

Scout started with a contradiction: it has never been easier to build software, yet it is still painfully easy to build the wrong thing.

During customer discovery, meaning is gradually diluted:

Customer conversation → notes → presentation → ticket → implementation → “That’s not what I meant.”

Every handoff looks reasonable on its own, but together they separate the final product from the customer’s original problem. Meanwhile, AI has made implementation dramatically faster without necessarily making discovery more accurate.

We wanted to close that gap. Scout is designed to preserve what the customer actually said, help people agree on the problem, and give Codex trusted context from which to build.

Scout finds the signal. Codex powers the build.

What Scout does

With explicit consent, Scout joins a live Zoom, Google Meet, or Microsoft Teams conversation and receives finalized, speaker-attributed utterances through Recall.ai.

As the conversation develops, Scout creates three connected, evidence-backed views:

  • Process — the steps, decisions, handoffs, delays, and pain points.
  • Organisation — the teams, roles, ownership, and reporting relationships.
  • Architecture — the systems, integrations, data stores, boundaries, and dependencies.

These are not three unrelated diagrams. They are projections of one shared business model, so the same customer statement can connect a process step, its owner, and the system supporting it.

Every finding remains linked to the customer utterances that support it. The operator can inspect that evidence, correct the model, add notes, edit relationships, distinguish the current state from the desired state, and mark findings as accepted, amended, or unsupported.

Nothing is handed to Codex until a human explicitly approves the exact revision. Scout then produces a private, integrity-checked delivery package containing the approved graph, minimized transcript, evidence, decisions, constraints, open questions, and specialist tasks. The operator can then select “Let Codex do its thing” to launch the approved work.

How we built it

Scout is a TypeScript and Node.js application built around four major integrations:

  • Recall.ai for finalized, attributed meeting transcription.
  • Codex app-server for persistent, structured meeting analysis and the post-call build handoff.
  • Mermaid for deterministic browser-rendered diagrams.
  • Server-Sent Events for live updates from the server to the operator and whiteboard views.

Each meeting receives one persistent Codex thread. Every analysis turn contains only:

  1. The current accepted BusinessGraph.
  2. The newly finalized utterances in chronological order.
  3. The list of customer utterances permitted as evidence.

Codex returns a complete graph through a strict output schema. Scout then performs deterministic schema, reference, evidence, identity, and semantic validation before atomically accepting the graph as a new revision.

The model never writes Mermaid syntax or chooses coordinates. It produces business meaning. Scout’s deterministic compilers transform that meaning into Process, Organisation, and Architecture diagrams.

Each diagram is rendered off-screen and checked for missing entities, overlapping nodes, clipped labels, edges crossing nodes, and other readability defects. If a candidate fails, Scout tries a deterministic fallback. The previous valid SVG remains visible until a replacement succeeds.

We used GPT-5.6 and Codex throughout Build Week as development collaborators. They helped us research diagram-generation approaches, design the semantic graph, implement the TypeScript application, generate and refine tests, diagnose live integration failures, review the interface, and challenge architectural decisions. We still made the final product and engineering decisions, reviewed the generated code, and relied on automated and browser-based verification before accepting changes.

Challenges we faced

Keeping customer evidence separate from operator influence

The interviewer naturally asks leading questions, but those questions must not silently become business facts. Scout therefore treats operator speech as conversational context while allowing only designated customer utterances to support claims.

Operator identity also had to remain correct. If someone selects the wrong participant and later corrects it, Scout invalidates the previous graph and Codex thread, preserves the transcript, and rebuilds the model using the corrected roles.

Generating readable diagrams from a changing conversation

Our first implementation pushed every concept through one generic flowchart. It worked technically, but processes did not resemble processes, organisation structures did not resemble organisation charts, and architecture diagrams lacked meaningful boundaries.

The breakthrough was realizing that Scout should be a semantic diagram compiler, not an AI drawing tool. One canonical graph now carries the meaning, while separate deterministic projectors create each specialist view.

Trusting structured output without trusting it blindly

A strict schema prevents malformed JSON, but it cannot prevent a semantically incorrect relationship. During one real analysis, Codex produced process relationships whose endpoints existed only in the architecture view. Scout’s validator correctly rejected the graph instead of showing a misleading diagram.

That failure led us to strengthen cross-view invariants and add regression tests for the exact case.

Keeping a live interface stable

Mermaid uses shared global rendering state, so simultaneous renders could interfere with one another. Scout now serializes rendering, prioritizes the active tab, updates inactive views during idle time, and retains each view independently.

We also chose finalized utterances instead of partial transcription. That introduces a small delay, but prevents the business model from repeatedly changing because an unfinished sentence was revised.

Turning a demo into a coherent product

Early versions were text-heavy and exposed too much implementation language. Evidence review, suggested questions, and the Codex handoff felt like separate demo features.

We simplified the interface around one journey: listen, understand, inspect, approve, and build. Detailed controls remain available through progressive disclosure, while the main experience stays focused on the conversation and diagrams.

What we learned

The biggest lesson was that an AI system should not be responsible for every layer.

Codex is excellent at interpreting language and proposing structured meaning. Deterministic software is better at validating references, enforcing evidence rules, managing revisions, compiling diagrams, measuring geometry, and deciding whether an artifact is safe to display.

We also learned that human approval is not friction to remove. In a system translating customer conversations into software decisions, approval is the trust boundary that makes automation useful.

Finally, we learned that reliability often matters more than apparent speed. Retaining the previous valid diagram, using finalized speech, and replacing complete graph revisions may look less sophisticated than streaming partial patches, but it produces a far more understandable and trustworthy experience.

Scout began as a live AI whiteboard. It became something more important: a bridge between what a customer says, what a team understands, and what Codex ultimately builds.

Built With

Share this project:

Updates