The Glass-Box Framework: Reasoning Observability for AI Agents

October 4, 2025 • 11 min read•Applied Agentic Engineering

Production AI agents fail to scale because teams can't see what's happening inside the reasoning loop. This article introduces the Glass-Box Framework, five concrete engineering practices to make agent reasoning transparent, debuggable, and reliable.

The V2 Clog

I've been talking to a lot of founders and engineers building Agentic workflow systems. There's a consistent pattern: V1 provides an instant high. The demo is impressive. Users are excited. Then the team tried to ship V2, and the entire process breaks down.

The symptoms are universal:

  • "The agent just does random things sometimes." Tool calls fire incorrectly. The LLM picks the wrong retrieval strategy.
  • "We can't reproduce the failure." A customer reports a bad answer. You re-run the same query. And it works perfectly.
  • "We don't know if the new prompt made it better or worse." You iterate on the system prompt. Vibes say it's improved. But few hours later, a different use case breaks.

This isn't a prompt engineering problem. It's a systems engineering problem. The reason V2 development stalls is that teams are flying blind. They don't have visibility into the agent's decision-making process. They're debugging final outputs, the symptom, not the reasoning chain that produced them. You can't iterate fast if you can't see what the machine is doing.

At Harvard Stem Cell, I learned this the hard way building deep research for cell diagnosis. Early on, I'd tune the prompts, ship a new version, and watch completion acceptance rates. But that's a lagging indicator. It told us what changed, not why. The breakthrough came when we started instrumenting the intermediate steps: What context was the model attending to? What tools was the agent calling? Which retrieval chunks were actually used in the final completion?

The core lesson: You can't debug what you can't see. And LLMs, by default, are opaque boxes.

The Opaque Box Problem: Building on Existing Infrastructure

Let's be clear: tools like Langfuse, Helicone, and LangSmith have done exceptional work. They've solved the infrastructure layer of LLM-ops—logs, traces, latency, cost, token counts, and I/O pairs. These are essential. They give you what I call "plumbing observability": the ability to see that your system is running, what it's consuming, and how long operations take.

But there's a gap. What these tools don't give you, by design and not by limitation, is "reasoning observability": visibility into why the agent made a specific decision, which part of your prompt influenced a tool call, what evidence the agent considered before making a claim.

Here's the difference:

Plumbing Observability (Langfuse, LangSmith):

  • Input: User query
  • Output: Agent's final response
  • Metadata: Latency, tokens, cost, tool calls fired
  • Value: Operational monitoring and cost tracking

Reasoning Observability (Glass-Box Principle):

  • Why did the agent choose Tool A over Tool B?
  • What evidence did the agent consider before making a claim?
  • Which section of the prompt influenced this decision?
  • What did the agent think the user was asking before retrieval?

Traditional debugging assumes deterministic systems. You set a breakpoint. You inspect state. You step through execution. But LLMs are non-deterministic black boxes. You can't set a breakpoint inside model's reasoning loop. The model's internal "thought process" is inaccessible.

The result? Teams resort to vibes-based debugging:

  1. User reports a bad answer.
  2. You read the agent's output. It's wrong.
  3. You tweak the prompt. "Be more careful." "Use this tool first."
  4. You re-test. It seems better.
  5. You ship it.
  6. Three days later, a different failure mode emerges.

This isn't sustainable. You're not debugging the system, you're playing whack-a-mole with symptoms.

The Glass-Box Framework: Engineering Agent Introspection

The solution is to architect agents that externalize their internal state. I call this the Glass-Box Framework. The Glass-Box Framework is a set of engineering practices for designing agent systems that emit structured, auditable artifacts exposing their intermediate reasoning steps, assumptions, knowledge boundaries, and decision logic.

This isn't about logging more data. It's about forcing the agent to explain itself in a machine-parseable format as part of its core execution loop.

Think of it like distributed system tracing. When you debug a complex microservices architecture, you don't just look at the final HTTP response. You look at the trace. You inspect each service hop. You see which caches were hit, which databases were queried, and where the latency spiked. The Glass-Box Principle applies the same rigor to agent reasoning.

The best thing is that the frontier models are remarkably good at following structured output instructions. You can compel them to emit their reasoning in XML, JSON, or any schema you define.

The five practices below are designed to work together as a debugging stack.

I. Structured Intent Deconstruction

The Problem

Most agents jump straight from user query to tool execution. The agent interprets "What's the status of Project Titan?" and immediately starts searching documents. But here's the failure mode: the agent's interpretation of the query is never externalized. If it misunderstands the intent, you only find out when the final answer is wrong.

Example failure:

  • User asks: "Is Project Titan a financial risk?"
  • Agent thinks: "User wants the current status of Project Titan."
  • Agent retrieves: General project updates, not budget or risk assessments.
  • Output: "Project Titan is on track." (Misses the actual concern.)

You can't debug this because you never saw the agent's intent model. The misinterpretation happened in the black box.

The Solution: Structured Intent Deconstruction

Force the agent to parse the user query into a structured "request spec" before it takes any action. This acts as the first auditable checkpoint in the reasoning chain.

Implementation Schema:

<INTENT_DECONSTRUCTION>
  <USER_INTENT>
    [Agent's interpretation of what the user is trying to achieve]
  </USER_INTENT>
  
  <KEY_ENTITIES>
    [Critical nouns, projects, dates, people extracted from the query]
  </KEY_ENTITIES>
  
  <CONSTRAINTS>
    [Any limitations, time bounds, or scope restrictions]
  </CONSTRAINTS>
  
  <REQUIRED_INFORMATION>
    [List of questions the agent must answer to fulfill the request]
  </REQUIRED_INFORMATION>
</INTENT_DECONSTRUCTION>

Before and After

Before (Opaque):

User: "Is Project Titan a financial risk?"
Agent: [Searches for "Project Titan"] 
Agent: "Project Titan is currently in Q2 development phase."

After (Glass-Box):

User: "Is Project Titan a financial risk?"

Agent Output:
<INTENT_DECONSTRUCTION>
  <USER_INTENT>
    User wants to assess financial risk exposure for Project Titan, 
    not just current status. This requires budget analysis, variance 
    tracking, and risk assessments.
  </USER_INTENT>
  
  <KEY_ENTITIES>
    - Project Titan
    - Financial risk
    - Q2 2025 (implied timeframe)
  </KEY_ENTITIES>
  
  <CONSTRAINTS>
    - Analysis must use post-2024 financial data
  </CONSTRAINTS>
  
  <REQUIRED_INFORMATION>
    1. What was the original budget for Project Titan?
    2. What is the current spend and burn rate?
    3. What are the latest risk assessments from finance?
    4. Are there any flagged budget overruns?
  </REQUIRED_INFORMATION>
</INTENT_DECONSTRUCTION>

[Agent proceeds to retrieve budget docs, not just status updates]

Why This Works

  1. Early Failure Detection: If the agent misunderstands the query, you catch it immediately, before it makes a wrong retrieval or an incorrect tool call.
  2. Auditable Requirements: The REQUIRED_INFORMATION list becomes a checklist you can verify against the final output.
  3. Prompt Debugging: If the agent consistently misinterprets a class of queries, you know the problem is in your intent parsing instructions, not your retrieval or synthesis logic.

Prompt Template:

Before answering, decompose the query into structured intent:
<INTENT_DECONSTRUCTION>
  <USER_INTENT>: Your interpretation of the true goal
  <KEY_ENTITIES>: Extract all critical entities
  <CONSTRAINTS>: Note any scope or time limitations
  <REQUIRED_INFORMATION>: List must-answer questions
</INTENT_DECONSTRUCTION>

Only after this is complete, proceed to retrieval and reasoning.

II. Exposing the Chain-of-Thought

The Problem

Many agents output answers as bald assertions. "The server crashed due to a memory leak." But there's no trail showing how the agent reached that conclusion. Did it analyze logs? Did it compare multiple hypotheses? Did it eliminate alternative explanations?

Without a visible reasoning chain, you can't:

  • Debug faulty logic
  • Identify where the agent made an unjustified leap
  • Understand if the agent is using the right strategy for the problem

The Solution: Explicit Chain-of-Thought Emission

Compel the agent to produce a human-readable narrative of its reasoning plan before executing tool calls or generating the final answer. This is distinct from just emitting markers (Practice III). This is about externalizing the strategy.

Implementation Schema:

<REASONING_CHAIN>
  <HYPOTHESIS>
    [What the agent believes is likely true, and why]
  </HYPOTHESIS>
  
  <EVIDENCE_REQUIRED>
    [What evidence would confirm or refute the hypothesis]
  </EVIDENCE_REQUIRED>
  
  <REASONING_STEPS>
    1. [First, I will do X because Y]
    2. [Then, I will check Z to validate A]
    3. [If Z shows B, then I will conclude C; otherwise D]
  </REASONING_STEPS>
  
  <ALTERNATIVE_EXPLANATIONS>
    [Other plausible hypotheses I'm considering]
  </ALTERNATIVE_EXPLANATIONS>
</REASONING_CHAIN>

Before and After

Before (Opaque):

User: "Why did the deployment fail at 3:15 PM?"
Agent: "The deployment failed because the database connection pool 
was exhausted."

After (Glass-Box):

User: "Why did the deployment fail at 3:15 PM?"

Agent Output:
<REASONING_CHAIN>
  <HYPOTHESIS>
    The deployment likely failed due to resource exhaustion 
    (memory, connections, or CPU) coinciding with the deployment 
    window.
  </HYPOTHESIS>
  
  <EVIDENCE_REQUIRED>
    - Server resource metrics (CPU, memory) at 3:15 PM
    - Database connection pool stats at deployment time
    - Application logs showing error types
    - Recent config changes in deployment script
  </EVIDENCE_REQUIRED>
  
  <REASONING_STEPS>
    1. First, I'll check application logs for error messages at 3:15 PM
    2. Then, I'll correlate with server metrics to identify resource spikes
    3. I'll examine the deployment script for recent changes
    4. If connection pool is maxed, I'll check for connection leaks
    5. I'll validate by checking if prior deployments had similar patterns
  </REASONING_STEPS>
  
  <ALTERNATIVE_EXPLANATIONS>
    - Cloud provider infrastructure event
    - Introduced bug in the deployment script itself
    - Network connectivity issue to database
  </ALTERNATIVE_EXPLANATIONS>
</REASONING_CHAIN>

[Agent proceeds to execute tool calls following this plan]

After analysis:
The database connection pool was exhausted (510/500 connections used). 
This was caused by a connection leak introduced in commit abc123f, 
which removed a critical `connection.close()` call in the retry logic.

Why This Works

  1. Strategy Visibility: You can now see if the agent is using the right approach. If it's missing obvious diagnostic steps, you can fix your prompt.
  2. Hypothesis Testing: The agent's ALTERNATIVE_EXPLANATIONS field reveals whether it's considering multiple causes or jumping to conclusions.
  3. Feedback Loop Clarity: When you improve your prompt (e.g., "Always check recent commits first"), you can verify the new reasoning chain reflects the change.

III. The Evidentiary Chain with Reasoning Markers

The Problem

Even when agents cite sources, there's often no direct link between a specific claim and a specific piece of evidence. The agent says, "According to the Q2 report, revenue is down 15%," but which section? Which table? What if there are two Q2 reports?

More critically: when the agent uses different sections of your prompt (e.g., a "DECISION MAKING" section vs. a "DATA RETRIEVAL" section), you have no idea which logic path was activated. This makes prompt debugging nearly impossible.

The Solution: Reasoning Markers + Citation Linking

This is a two-part system:

Part 1: Section Markers
Instrument your system prompt with explicit sections, and compel the agent to emit a marker every time it uses that section's logic.

Part 2: Evidentiary Citations
Force the agent to link every factual claim to a specific source location (document ID, section, table, paragraph).

Implementation Schema:

<!-- In your system prompt -->
<DECISION_MAKING>
  [Your decision logic here]
  
  RULE: If you use this section, output: <marker:decision_making>
</DECISION_MAKING>

<DATA_RETRIEVAL>
  [Your retrieval strategy here]
  
  RULE: If you use this section, output: <marker:data_retrieval>
</DATA_RETRIEVAL>

<!-- In agent output -->
<REASONING_OUTPUT>
  <MARKERS_USED>
    - <marker:decision_making>
    - <marker:data_retrieval>
  </MARKERS_USED>
  
  <EVIDENTIARY_CHAIN>
    <CLAIM>Revenue declined 15% in Q2</CLAIM>
    <EVIDENCE source="Q2_Financial_Report.pdf" section="3.2" table="Table_5">
      Q2 revenue: $42.3M (vs. Q1: $49.8M = -15.1%)
    </EVIDENCE>
    
    <CLAIM>This was primarily driven by customer churn</CLAIM>
    <EVIDENCE source="Customer_Analytics_Dashboard" query="churn_rate_Q2_2025">
      Q2 churn rate: 8.2% (vs. Q1: 4.1%)
    </EVIDENCE>
  </EVIDENTIARY_CHAIN>
</REASONING_OUTPUT>

Before and After

Before (Opaque):

User: "Why did Q2 revenue decline?"
Agent: "Revenue declined due to customer churn and delayed enterprise deals."

(No way to verify this. Which customers? Which deals? How did the agent know?)

After (Glass-Box):

User: "Why did Q2 revenue decline?"

Agent Output:
<REASONING_OUTPUT>
  <MARKERS_USED>
    - <marker:data_retrieval> (Used retrieval strategy for financial docs)
    - <marker:decision_making> (Applied root cause analysis framework)
  </MARKERS_USED>
  
  <EVIDENTIARY_CHAIN>
    <CLAIM>Revenue declined 15% in Q2 2025</CLAIM>
    <EVIDENCE source="Q2_Financial_Report.pdf" section="3.2" table="Revenue_Summary">
      Q2 revenue: $42.3M | Q1 revenue: $49.8M | Variance: -15.1%
    </EVIDENCE>
    
    <CLAIM>Customer churn increased significantly</CLAIM>
    <EVIDENCE source="Customer_Analytics_Dashboard" timestamp="2025-07-15">
      Q2 churn rate: 8.2% (103 customers) | Q1 churn rate: 4.1% (51 customers)
    </EVIDENCE>
    
    <CLAIM>Three major enterprise renewals were delayed</CLAIM>
    <EVIDENCE source="Sales_Pipeline_Slack_Export" channel="enterprise-deals" date="2025-06-28">
      Message from @sarah_sales: "Acme Corp ($2.1M), TechCo ($1.8M), 
      and GlobalSystems ($1.5M) all pushed renewals to Q3 due to 
      budget freezes."
    </EVIDENCE>
  </EVIDENTIARY_CHAIN>
</REASONING_OUTPUT>

Analysis: Q2 revenue decline was driven by both higher churn (8.2% vs 4.1%) 
and $5.4M in delayed enterprise renewals. Immediate action required on 
retention and enterprise relationship management.

Why This Works

  1. Hallucination Detection: You can programmatically verify every claim. If the agent cites Table_5 from Q2_Report.pdf, you fetch that table and check.
  2. Prompt Section Debugging: If the agent is not emitting <marker:data_retrieval>, you know it's skipping your retrieval logic. Fix the prompt.
  3. Traceability: Every claim has an audit trail. You can trace a wrong answer back to a bad source or a bad inference step.

IV. The Epistemic Boundary Report

The Problem

Agents often produce answers with hidden uncertainty. They state facts confidently, even when they're interpolating or guessing. The user has no way to know which parts of the answer are grounded in evidence and which are speculative.

Worse, the agent itself doesn't know what it doesn't know. It can't flag gaps in the provided context or warn about potential blind spots.

The Solution: Explicit Knowledge Mapping

Before generating a final answer, force the agent to map the boundaries of its knowledge for the given query. This is inspired by the Rumsfeld's epistemology framework ("known knowns, known unknowns, unknown unknowns").

Implementation Schema:

<EPISTEMIC_BOUNDARY_REPORT>
  <KNOWN_KNOWNS>
    [Facts that can be definitively stated from the provided context]
  </KNOWN_KNOWNS>
  
  <KNOWN_UNKNOWNS>
    [Specific questions the agent knows it cannot answer with current data]
  </KNOWN_UNKNOWNS>
  
  <HYPOTHESIZED_UNKNOWN_UNKNOWNS>
    [What information *might exist* that the agent is unaware of, 
     which could fundamentally change the conclusion]
  </HYPOTHESIZED_UNKNOWN_UNKNOWNS>
  
  <CONFIDENCE_ASSESSMENT>
    [Overall confidence level and the weakest link in the reasoning chain]
  </CONFIDENCE_ASSESSMENT>
</EPISTEMIC_BOUNDARY_REPORT>

Before and After

Before (Opaque):

User: "What caused the production outage on June 15th?"
Agent: "The outage was caused by a deployment of version 2.4.1 
which introduced a memory leak."

(Sounds definitive. But is the agent guessing? What evidence is missing?)

After (Glass-Box):

User: "What caused the production outage on June 15th?"

Agent Output:
<EPISTEMIC_BOUNDARY_REPORT>
  <KNOWN_KNOWNS>
    - Production outage occurred at 14:23 UTC on June 15, 2025
    - Version 2.4.1 was deployed at 14:18 UTC (5 minutes before outage)
    - Server logs show OOMKilled events starting at 14:23 UTC
    - Memory usage spiked from 4.2GB to 7.8GB in 3 minutes
  </KNOWN_KNOWNS>
  
  <KNOWN_UNKNOWNS>
    - Which specific code change in v2.4.1 caused the memory spike
    - Whether there was an external traffic spike coinciding with deploy
    - Whether staging environment tests covered this failure mode
    - If there were prior warnings in canary deployment
  </KNOWN_UNKNOWNS>
  
  <HYPOTHESIZED_UNKNOWN_UNKNOWNS>
    - There could be a rare race condition triggered only under 
      production load patterns
    - A third-party library dependency updated in v2.4.1 may have 
      a latent memory leak not visible in tests
    - Infrastructure-level event (e.g., node memory pressure from 
      co-located services) could be a contributing factor
  </HYPOTHESIZED_UNKNOWN_UNKNOWNS>
  
  <CONFIDENCE_ASSESSMENT>
    Confidence: HIGH that v2.4.1 deployment is correlated with outage.
    Confidence: MEDIUM on root cause being memory leak (temporal 
    correlation is strong, but no code-level evidence yet).
    
    Weakest link: No visibility into which specific code path leaked memory.
    
    Recommended next steps: 
    1. Profile v2.4.1 under load in staging
    2. Review commit diff for memory management changes
    3. Check for dependency updates in v2.4.1
  </CONFIDENCE_ASSESSMENT>
</EPISTEMIC_BOUNDARY_REPORT>

Conclusion: The outage is strongly correlated with the v2.4.1 deployment. 
Memory leak is the most likely cause, but root cause analysis requires 
code profiling and commit review to isolate the specific change.

Why This Works

  1. Uncertainty Quantification: This tells you which parts of the answer are solid and which are speculative.
  2. Gap Identification: The KNOWN_UNKNOWNS list tells you exactly what additional data to collect.
  3. Blind Spot Awareness: The HYPOTHESIZED_UNKNOWN_UNKNOWNS section forces the agent to imagine what it might be missing—a meta-cognitive skill that surfaces risk.
  4. Prompt Improvement: If the agent consistently flags the same KNOWN_UNKNOWNS across queries, you can update your retrieval system to proactively fetch that data.

V. Axiomatic Lens Rotation

The Problem

Every agent has implicit biases encoded in its training data and your system prompt. These biases manifest as hidden assumptions ("axioms") that shape the agent's reasoning. For a retrieval system:

  • "Prioritize recall over precision" (cast a wide net)
  • "Prioritize precision over recall" (only high-confidence matches)

For a medical research agent:

  • "Prioritize recent studies" (assume newer is better)
  • "Prioritize high-impact journals" (assume quality over recency)

But these axioms are never stated. You don't know which lens the agent is using. And worse, you can't test if the agent's reasoning is robust to different problem framings.

The Solution: Explicit Axiom Specification and Rotation

Force the agent to make its core operating assumption explicit, then re-run the same analysis under a different axiom. This reveals how much the agent's conclusion depends on its default bias.

Implementation Schema:

<AXIOMATIC_LENS_ROTATION>
  <PRIMARY_ANALYSIS>
    <AXIOM>Optimize for [X]</AXIOM>
    <REASONING>[Analysis under this lens]</REASONING>
    <CONCLUSION>[Recommendation]</CONCLUSION>
  </PRIMARY_ANALYSIS>
  
  <ALTERNATIVE_LENS>
    <AXIOM>Optimize for [Y]</AXIOM>
    <REASONING>[Re-analysis under this lens]</REASONING>
    <CONCLUSION>[Alternative recommendation]</CONCLUSION>
  </ALTERNATIVE_LENS>
  
  <LENS_COMPARISON>
    [How the conclusions differ and what that reveals about trade-offs]
  </LENS_COMPARISON>
</AXIOMATIC_LENS_ROTATION>

Before and After

Before (Opaque):

User: "What's the best retrieval strategy for finding cancer treatment research?"
Agent: "Use semantic search with a 0.7 similarity threshold to balance 
recall and precision."

(But this assumes one specific trade-off. What if the user needs exhaustive recall?)

After (Glass-Box):

User: "What's the best retrieval strategy for finding cancer treatment research?"

Agent Output:
<AXIOMATIC_LENS_ROTATION>
  <PRIMARY_ANALYSIS>
    <AXIOM>Optimize for precision (minimize false positives)</AXIOM>
    <REASONING>
      For clinical decision-making, a false positive (irrelevant study 
      presented as relevant) is costly. It wastes oncologist time and 
      could introduce noise into treatment planning.
      
      Strategy:
      - Semantic similarity threshold: 0.85 (high confidence only)
      - Require exact entity matches (drug names, cancer types)
      - Prioritize systematic reviews and meta-analyses
      - Expected recall: ~60% | Expected precision: ~92%
    </REASONING>
    <CONCLUSION>
      Use high-threshold semantic search (0.85) + entity filters.
      Accept lower recall to maintain high precision for clinical use.
    </CONCLUSION>
  </PRIMARY_ANALYSIS>
  
  <ALTERNATIVE_LENS>
    <AXIOM>Optimize for recall (minimize false negatives)</AXIOM>
    <REASONING>
      For exploratory research or rare cancer types, a false negative 
      (missing a relevant study) is the bigger risk. You might miss a 
      breakthrough treatment option.
      
      Strategy:
      - Semantic similarity threshold: 0.65 (cast wider net)
      - Use expanded query with synonyms and related terms
      - Include preprints and case studies, not just peer-reviewed
      - Expected recall: ~88% | Expected precision: ~71%
    </REASONING>
    <CONCLUSION>
      Use lower-threshold semantic search (0.65) + query expansion.
      Accept lower precision to maximize recall for exploratory research.
    </CONCLUSION>
  </ALTERNATIVE_LENS>
  
  <LENS_COMPARISON>
    The two strategies produce opposite trade-offs:
    
    Precision-optimized:
    - Best for: Clinical decision-making, treatment protocols
    - Risk: Might miss emerging research or rare case studies
    
    Recall-optimized:
    - Best for: Exploratory research, rare cancers, novel treatments
    - Risk: Oncologist must manually filter more irrelevant results
    
    The right choice depends on the user's context:
    - If you're an oncologist finalizing a treatment plan → Precision lens
    - If you're a researcher surveying the landscape → Recall lens
  </LENS_COMPARISON>
</AXIOMATIC_LENS_ROTATION>

Why This Works

  1. Bias Detection: You can see which axiom the agent defaults to, and whether it's appropriate for your context.
  2. Robustness Testing: If the agent's conclusion completely flips under a different lens, the decision is axiom-dependent. You need more data or clearer constraints.
  3. Trade-off Visibility: The LENS_COMPARISON section makes implicit trade-offs explicit, helping users make informed decisions.
  4. Prompt Calibration: If your agent consistently uses the wrong axiom, you can hardcode the right one in your system prompt.

Conclusion: Debugging the Reasoning Loop

Let's zoom out. The reason most AI agent projects stall at V2 is not that the models aren't good enough. The models are exceptional. The reason is that teams treat agents like black boxes and debug them like traditional software. That doesn't work.

Building production-ready agents is not about better prompts alone. It's about better systems engineering. You need to architect observability into the reasoning loop from day one.

The Glass-Box Framework gives you that architecture. Five practices that make agent reasoning transparent, debuggable, and improvable:

  1. Structured Intent Deconstruction: Catch misinterpretations before they cascade.
  2. Chain-of-Thought: See the agent's strategy before it executes.
  3. Evidentiary Chain + Markers: Trace every claim back to its source and prompt section.
  4. Epistemic Boundary Report: Quantify uncertainty and surface knowledge gaps.
  5. Axiomatic Lens Rotation: Reveal hidden biases and test reasoning robustness.

Modern LLMs can follow structured output instructions. You can implement these practices with prompt engineering alone. No custom models, no fine-tuning, no infrastructure rewrites.

Start with one agent. Implement Intent Deconstruction and Evidentiary Chain. Run 20 queries in staging. Review the traces. You'll immediately see what the agent is actually doing (not what you thought it was doing) and where your prompt is incomplete (the gaps you didn't know existed).

The teams that win in AI are the teams that figure out how to iterate fast on agent systems. The Glass-Box Framework is how you do that.