Agent Tracing & Observability

Spans, Traces, and Events

Before you instrument anything, you need to understand the data model. Tracing has precise terminology, and using it correctly will save you hours of confusion when you're reading documentation for any tracing tool.

A trace represents a single end-to-end operation. In agent terms, one trace equals one user query from the moment it arrives to the moment the final response is returned. A trace has a unique trace_id and contains one or more spans.

A span represents a single unit of work within a trace. Spans have a start time, an end time, a name, and optional metadata. Critically, spans have parent-child relationships. The root span is the top-level operation. Child spans represent sub-operations. This gives you a tree structure.

An event (sometimes called a "log" in OpenTelemetry terminology) is a timestamped annotation attached to a span. Events don't have duration; they mark a point in time. "Tool call started," "Cache hit," "Retry initiated" are events.

Here's how an agent query decomposes into spans:

Notice the structure. The root span encompasses the entire operation. Each LLM call and tool execution is a child span. Events are annotations within spans. You can see the data flow: the first LLM call decided to search, the tool returned results, the second LLM call decided to read a specific document, the tool returned content, and the third LLM call generated the summary.

The Span Data Model in Python

Let's formalize this. Here's a Python dataclass that models a span suitable for LLM agent tracing:

Standard Metadata Fields

Every tracing tool uses slightly different field names, but the following metadata should be captured on every LLM span. This table serves as your instrumentation checklist:

Trace ID Propagation in Multi-Agent Systems

In simple setups, one agent handles one query. In production systems, you often have orchestrator agents that delegate to specialist agents. A command dispatcher might route a request to a "research agent," which calls a "summarization agent," which calls a "citation verification agent." Each agent might run in a different process or even a different service.

Trace ID propagation ensures that all spans from all agents in a single user query share the same trace_id. Without this, you see five disconnected traces instead of one coherent tree.

The standard approach, borrowed from OpenTelemetry, is to pass trace context via headers or function arguments:

How OpenTelemetry Maps to LLM Agent Concepts

OpenTelemetry (OTel) is the industry standard for distributed tracing. Its data model maps cleanly to LLM agents, but requires some semantic conventions that aren't yet standardized (there is an active working group for "GenAI semantic conventions"):

• OTel Trace = Agent conversation or task execution
• OTel Span = LLM call, tool execution, or agent reasoning step
• OTel SpanKind.CLIENT = Outgoing LLM API call
• OTel SpanKind.INTERNAL = Agent's decision-making logic
• OTel Attributes = Model name, token counts, cost, tool metadata
• OTel Events = Tool selection, cache hits, guardrail checks
• OTel Links = References between related traces (e.g., a follow-up query linked to the original)

The emerging convention uses attribute names like gen_ai.system (e.g., "anthropic"), gen_ai.request.model, gen_ai.usage.input_tokens, and gen_ai.usage.output_tokens. If you adopt these now, your traces will be compatible with any OTel-based backend.

The Observability Tools Ecosystem in 2026

The LLM observability space has matured rapidly. In 2023, you had LangSmith and not much else. In 2026, there are credible options across the spectrum from open-source self-hosted to fully managed SaaS. Choosing the right tool depends on your team size, budget, compliance requirements, and existing infrastructure.

I'm going to give you my honest, opinionated assessment of each major tool. I've used most of these in production or evaluated them seriously. Where I haven't, I'll say so.

LangSmith (by LangChain)

LangSmith is the most widely adopted LLM tracing tool, largely because of LangChain's market dominance in agent frameworks. If you're already using LangChain or LangGraph, LangSmith integrates with zero additional code. You literally import it and traces appear.

Strengths: Excellent UI for trace visualization, built-in evaluation framework, dataset management for testing, hub for sharing prompts. The trace tree view is best-in-class. Playground for iterating on prompts with trace data.

Weaknesses: Tightly coupled to the LangChain ecosystem. If you're using the Anthropic or OpenAI SDKs directly, integration requires more work. Pricing can surprise you at scale. The platform has had reliability issues under heavy load. Not open source (LangSmith is SaaS, though LangChain the framework is open source).

My take: If you're a LangChain shop, just use it. If you're not, look elsewhere.

Braintrust

Braintrust started as an evaluation platform and grew into tracing. This heritage shows in the best ways: their eval framework is exceptional, and traces integrate directly with eval scores. You can trace a production query, add it to a dataset, run evals against it, and compare model versions, all in one platform.

Strengths: Best-in-class evaluation integration. Clean SDK that works with any LLM provider. Excellent logging API that's framework-agnostic. Good proxy mode for zero-code tracing. Strong cost analytics.

Weaknesses: Smaller community than LangSmith. Some advanced features require the paid tier. The UI, while functional, isn't as polished as LangSmith's trace viewer.

My take: If evaluation is your primary concern alongside tracing, Braintrust is the best choice. The combined eval+trace workflow is unmatched.

Arize Phoenix

Phoenix is the open-source option from Arize AI. It's a standalone tool you run locally or self-host. It uses OpenTelemetry under the hood, which means your instrumentation is portable: if you outgrow Phoenix, your traces work with any OTel-compatible backend.

Strengths: Fully open source (Apache 2.0). Self-hosted, so your data never leaves your infrastructure. OTel-native, so you're not locked in. Good for compliance-sensitive environments. Free. Active community.

Weaknesses: You own the infrastructure. No managed service (though Arize's commercial platform offers one). The UI is functional but spartan compared to commercial tools. Less polished eval integration.

My take: If you need self-hosted and open source, Phoenix is the clear winner. It's also a great starting point if you're not sure what you need yet, since it's free and OTel-based.

Helicone

Helicone takes a unique approach: it's a proxy. You change your API base URL from api.anthropic.com to anthropic.helicone.ai, and every request is logged automatically. Zero code changes to your application.

Strengths: Literally zero-code setup for basic tracing. Works with any SDK or framework. Excellent cost dashboard. Good for getting started quickly. Rate limiting and caching features built in.

Weaknesses: Being a proxy adds latency (typically 10-50ms). You're routing all your LLM traffic through a third party. Limited ability to trace non-LLM operations (tool calls, custom logic). The proxy model makes it hard to capture tool execution details.

My take: Helicone is perfect for teams that want immediate visibility with zero engineering effort. It's not sufficient for deep agent debugging, but it's a great complement to a more comprehensive solution.

Weights & Biases Weave

W&B Weave brings the maturity of W&B's ML experiment tracking to LLM observability. If your team already uses W&B for model training, Weave provides a unified platform for both traditional ML and LLM ops.

Strengths: Integration with W&B's broader ML platform. Good versioning for prompts and models. Strong visualization. Enterprise features (SSO, audit logs, etc.).

Weaknesses: The LLM-specific features feel bolted onto a platform designed for traditional ML. Pricing can be opaque. The learning curve is steeper if you're not already a W&B user.

My take: Use it if you're already in the W&B ecosystem. Don't adopt W&B just for LLM tracing.

OpenTelemetry (Direct)

You can skip all vendor tools and instrument your agents with raw OpenTelemetry. Send traces to any OTel-compatible backend: Jaeger, Grafana Tempo, Honeycomb, Datadog, or your own collector. This gives you maximum flexibility and zero vendor lock-in.

Strengths: Industry standard. No vendor lock-in. Works with your existing observability stack. You control everything.

Weaknesses: You build everything yourself. No pre-built LLM trace viewer. No eval integration. No cost analytics dashboard. Significant engineering investment.

My take: This is the right choice for platform teams at scale (50+ engineers) who want to integrate LLM tracing into their existing observability stack. It's overkill for small teams.

Anthropic's Usage API

Anthropic provides usage tracking through the API response's usage field and the admin API. It's not tracing in the traditional sense, but it gives you token counts, costs, and rate limit information per request.

Strengths: Built in. No additional setup. Accurate token counts straight from the source.

Weaknesses: Not a tracing tool. No trace visualization, no span trees, no eval integration. Just per-request metrics.

My take: Always capture the usage data from API responses. Layer a real tracing tool on top.

Comprehensive Comparison

Build vs. Buy: The Decision Framework

The build vs. buy decision for LLM tracing depends on three factors:

1. Team size: Under 10 engineers? Buy. The engineering cost of building and maintaining a tracing system exceeds the subscription cost of any SaaS tool. 50+ engineers with a platform team? Build on OTel, potentially with an open-source frontend like Phoenix.
2. Data sensitivity: If your prompts contain PII, PHI, or proprietary data, self-hosted is often a compliance requirement. This narrows your options to Phoenix, Helicone (self-hosted), or raw OTel.
3. Existing infrastructure: If you already have Datadog or Grafana, adding OTel-based LLM tracing to your existing dashboards is often simpler than adopting a new SaaS tool. Your ops team already knows how to manage alerts, dashboards, and retention in the existing system.

Opinionated Recommendations by Team Size

Solo developer or small startup (1-5 people): Start with Helicone for instant cost visibility. Add Braintrust when you need evals. Total cost: $0-50/month.

Growth-stage team (5-20 people): Use Braintrust or LangSmith as your primary platform. Capture everything. The investment in trace infrastructure will pay back 10x when you're debugging production issues at 2 AM. Total cost: $200-500/month.

Enterprise / platform team (20+ people): Build on OpenTelemetry. Use Phoenix or a commercial OTel backend (Honeycomb, Grafana Cloud). Integrate with your existing observability stack. Build custom dashboards. This is a 2-4 week engineering project but gives you maximum control and zero vendor lock-in.

From Theory to Code

This is the hands-on module. We're going to build real instrumentation for real agent patterns. Every code example is designed to be copied into a production codebase with minimal modification. I'll cover five patterns, from simple to complex.

Pattern 1: A Basic Trace Decorator

The simplest useful instrumentation is a decorator that wraps any LLM call, captures timing, token usage, and cost, and stores the span. This works with any LLM provider.

Pattern 2: Tracing Claude Messages API with Tool Use

This is the pattern you'll use most often: tracing a Claude conversation that includes tool use. The key insight is that you need to trace both the LLM calls and the tool executions, and connect them with parent-child relationships.

Pattern 3: Multi-Turn Conversation Tracing with Parent/Child Spans

In a real conversation, a user might send multiple messages. Each message triggers a new agent run, but they're all part of the same session. You need a session-level trace that contains multiple conversation-level traces.

Pattern 4: OpenTelemetry Instrumentation for Production

For production systems, you want your traces to flow into your standard observability stack. Here's how to instrument an agent with OpenTelemetry, using the emerging GenAI semantic conventions:

Pattern 5: Braintrust Integration

Braintrust offers one of the cleanest APIs for combined tracing and evaluation. Their @traced decorator and logging API make it straightforward to capture traces and then score them:

Key Instrumentation Principles

• Instrument at the boundary: Trace every external call (LLM API, tool execution, database query). Internal logic between calls is usually not worth tracing individually.
• Capture inputs and outputs: Without the actual prompt text and completion text, your traces are just timing data. Capture the full content, truncating only if necessary for storage.
• Use context managers or decorators: Manual span start/stop is error-prone. Context managers guarantee spans are closed even when exceptions occur.
• Don't forget error traces: Failed calls are the most valuable traces. Always capture the exception message and stack trace in the span metadata.
• Make it opt-out, not opt-in: Tracing should be on by default. Use an environment variable like TRACING_ENABLED=false to disable, not TRACING_ENABLED=true to enable.

When Your Agent Goes Wrong

Agents fail in ways that traditional software doesn't. They don't just throw exceptions; they make subtly wrong decisions, hallucinate tool parameters, get stuck in loops, and produce plausible-sounding but incorrect output. Traces are your X-ray machine. Here's how to use them.

Failure Mode 1: Wrong Tool Selection

The agent receives "What's the weather in Tokyo?" and calls search_documents instead of get_weather. In your trace, this shows up as a tool span with an unexpected tool_name. The fix might be in your tool descriptions, your system prompt, or your tool schema. Without the trace showing exactly which tools were available and which was chosen, you're guessing.

Failure Mode 2: Hallucinated Parameters

The agent calls the right tool but invents a parameter value. For example, search_files(directory="/home/user/documents/Q3") when no such directory exists. The tool returns an error or empty result, the agent retries with another fabricated path, and the loop begins. In your trace, you'd see the tool_args metadata revealing the hallucinated path.

Failure Mode 3: Infinite Loops

The most expensive failure mode. The agent calls a tool, gets an unsatisfying result, decides to try again with slightly different parameters, gets another unsatisfying result, and repeats. Your trace will show a growing chain of nearly identical spans. In a task dispatcher system with 30+ scheduled tasks, one looping task can consume your entire daily budget.

The Latency Waterfall

A visual waterfall shows each span as a horizontal bar, positioned by start time and sized by duration. This immediately reveals where time is spent:

From this waterfall, you can immediately see that llm_call_2 is the bottleneck. It's slow because it's processing 8,400 input tokens (the original prompt plus the search results from the first tool call). This tells you: maybe you should truncate search results before passing them to the next LLM call.

Trace Replay: Re-running Failed Traces

One of the most powerful debugging techniques is trace replay: take a failed trace, extract the exact inputs at each step, and re-run them deterministically with temperature=0. This lets you reproduce the failure reliably.

The Debugging Checklist

Building a Trace Analyzer

Instead of manually inspecting every trace, build an analyzer that flags anomalies automatically. Here's a practical implementation:

Comparing Good vs. Bad Traces

One of the most effective debugging techniques is side-by-side trace comparison. Take a trace where the agent succeeded and one where it failed for a similar query. Diff them systematically:

• Tool sequence: Did the failing trace call tools in a different order? Did it call extra tools? Did it skip a tool the good trace used?
• Tool arguments: Were the arguments to the same tool different? Was one set of arguments more specific?
• Token counts: Did the failing trace have significantly more input tokens at any turn? This suggests context pollution.
• Timing: Was any span in the failing trace unusually slow? Timeouts can cause cascading failures.
• Error propagation: Did an early error go unhandled, causing downstream failures?

Cost Debugging: "Why Did This Query Cost $2.50?"

When a single query costs significantly more than expected, the trace tells you exactly where the money went. Sort spans by cost (or by input_tokens + output_tokens if you haven't computed cost) and look at the top offenders. Common causes:

• Context accumulation: Each turn includes the full conversation history. By turn 15, you're sending 50,000 tokens per call. The trace shows input token counts growing linearly.
• Large tool results: A tool returns a 10,000-word document, which gets included verbatim in the next prompt. The trace shows the tool result size in the span metadata.
• Model escalation: Your router sent the query to Opus when Sonnet would have sufficed. The trace shows which model was used on each span.
• Retry storms: An intermittent error caused three retries, each with the full context. The trace shows duplicate spans with growing latency.

From Debugging to Dashboards

Debugging is reactive. You look at traces after something goes wrong. Monitoring is proactive: you watch aggregate metrics to catch problems before users report them. Production agent monitoring requires a specific set of metrics that traditional web service monitoring doesn't cover.

The Golden Signals for Agent Systems

Google's Site Reliability Engineering book defines four golden signals: latency, traffic, errors, and saturation. For LLM agents, we need to extend these with agent-specific signals:

Building a Monitoring Class

Here's a production-ready metrics collector that aggregates trace data into the golden signals above:

SLOs for Agent Systems

Service Level Objectives for agents are tricky because "correct" is harder to define than for traditional APIs. A REST endpoint either returns the right data or it doesn't. An agent might return a response that's 80% correct, or correct but unhelpfully verbose, or technically correct but misses the user's intent.

Practical SLOs for agent systems:

• Availability SLO: 99.5% of agent invocations complete without an unhandled exception. This is your floor. If the agent crashes, that's always a failure.
• Latency SLO: 95% of queries complete in under 10 seconds, 99% in under 30 seconds. Adjust based on your use case. Interactive chat needs p99 < 10s. Batch processing can tolerate minutes.
• Cost SLO: 99% of queries cost less than $0.50. The 1% allows for complex multi-tool queries. Anything exceeding $0.50 should be investigated.
• Quality SLO (the hard one): This requires user feedback integration. Set a target like "90% of rated responses receive positive feedback." Track this with trace-correlated thumbs-up/thumbs-down signals.

User Feedback Integration

The most valuable signal in agent monitoring is user feedback, but only if it's correlated with traces. When a user clicks thumbs-down, you need to instantly link that feedback to the specific trace that generated the response. This lets you:

• Pull up the exact trace and see what went wrong
• Aggregate negative feedback by tool, model, or query type
• Identify systematic issues (e.g., "all queries involving the calendar tool get negative feedback")
• Build evaluation datasets from real failures

Implementation is straightforward: when generating a response, attach the trace_id to the response payload. When the user submits feedback, log it with the same trace_id. Your dashboard can then join these datasets.

Production Alerting Channels

Your monitoring system should alert through multiple channels based on severity:

• Critical (P1): Error rate > 10%, complete agent downtime, or a single trace costing > $5. Route to PagerDuty / on-call phone.
• Warning (P2): Error rate > 5%, cost spike > 2x baseline, latency p99 > 30s. Route to Slack #agent-alerts channel.
• Info (P3): New failure patterns, cache hit rate drop, model routing anomalies. Route to daily digest email.

Tracing as a Cost Reduction Tool

Tracing isn't just for debugging. It's your most powerful tool for cost optimization. Without per-query cost visibility, you're optimizing blind. With it, you can identify the 20% of queries consuming 80% of your budget and target them precisely.

Understanding Model Costs

First, internalize the cost landscape. Prices as of mid-2026 (always verify current pricing):

The cost difference between Haiku and Opus is 20x. That means routing even 30% of your traffic from Opus to Haiku could reduce your bill by 50%. But you can only identify which queries are Haiku-eligible if you have trace data showing query complexity.

Identifying Expensive Traces

The first step in cost optimization is understanding your cost distribution. Build a cost analyzer that ranks traces by expense and identifies patterns:

Prompt Caching Strategies

Anthropic's prompt caching can reduce input token costs by up to 90% for repeated prefixes. Tracing tells you whether caching is actually working:

• Track cache_creation_input_tokens and cache_read_input_tokens in your spans. The Anthropic API returns these in the usage object. If cache_read_input_tokens is zero, your cache isn't being hit.
• Common cache miss causes: System prompt changed between calls (even a single character invalidates the cache), conversation history order changed, tools list modified.
• Optimization: Keep your system prompt and tools definition stable. Put the static parts first (they form the cache prefix). Put dynamic content (user message, conversation history) last.

In your traces, add a computed field: cache_hit_rate = cache_read_input_tokens / (cache_read_input_tokens + input_tokens). Dashboard this over time. A sudden drop means something invalidated your cache.

Token Waste Analysis

Common sources of token waste, identifiable through traces:

• Over-long system prompts: Your system prompt is 3,000 tokens but most of it is rarely relevant. Trace analysis can show which parts of the system prompt are actually referenced in responses (by comparing system prompt content with response content). Trim the unused parts.
• Unnecessary tool calls: The agent calls get_current_time on every query, even when time is irrelevant. Trace analytics showing tool call frequency per query type reveal this pattern.
• Redundant context: The agent includes full search results when a summary would suffice. Traces show the tool result size vs. how much of it appears in the final response.
• Conversation history bloat: In multi-turn conversations, each turn includes all previous turns. Traces show input token counts growing linearly per turn. Solutions: summarize older turns, use a sliding window, or use prompt caching aggressively.

A/B Testing Model Versions

Traces enable rigorous A/B testing of model versions. Route 10% of traffic to a new model, capture traces from both, and compare:

• Quality: Correlate user feedback scores with model version
• Cost: Compare average cost per trace between versions
• Latency: Compare p50/p95/p99 latency
• Tool use patterns: Does the new model use tools differently? More efficiently?
• Error rates: Does the new model fail more often?

In a multi-model setup where you route between Opus, Sonnet, and Haiku based on query complexity, traces give you the ground truth for your routing decisions. If your router sends 40% of traffic to Opus but trace analysis shows 60% of those queries are simple enough for Sonnet, you've found a significant cost optimization.

Reference Architecture

Let's bring everything together. Here's a reference architecture for a production agent system with full observability, modeled after a Cowork-style setup with 30+ scheduled tasks, a command dispatcher, and multi-model routing:

Choosing the Right Tool for Your Scale

Here's a decision tree to guide your tool selection:

Self-Hosted vs. SaaS: The Tradeoffs

This decision deserves careful consideration because it affects cost, maintenance burden, and data governance:

• SaaS (LangSmith, Braintrust, Helicone cloud): Zero infrastructure maintenance. Automatic updates. Shared community features. But: your prompt data leaves your infrastructure, which may violate compliance requirements. Costs scale linearly with volume. You're dependent on the vendor's uptime and roadmap.
• Self-Hosted (Phoenix, OTel + Tempo, Helicone self-hosted): Full data control. Fixed infrastructure cost (doesn't scale with query volume once provisioned). You can customize everything. But: you own the ops burden. Upgrades, scaling, backups, and monitoring the monitoring system are all your responsibility.

My recommendation: start with SaaS to move fast, build a thin abstraction layer, and migrate to self-hosted when you hit one of these triggers: (a) your monthly SaaS bill exceeds the cost of a dedicated VM, (b) a compliance requirement demands data residency, or (c) you need customization the SaaS doesn't support.

OpenTelemetry as the Universal Standard

Regardless of which tool you choose, instrument with OpenTelemetry semantics. Here's why:

• Portability: OTel traces can be exported to any compatible backend. Switch from Phoenix to Grafana Tempo to Datadog without changing your application code.
• Ecosystem: OTel has auto-instrumentation libraries for HTTP clients, databases, and message queues. Your agent's non-LLM dependencies get traced for free.
• Standards: The GenAI semantic conventions are being standardized. Early adoption means your traces will be compatible with future tooling.
• Correlation: OTel lets you correlate LLM traces with infrastructure traces. An agent that's slow because the database is slow shows up as one connected trace, not two disconnected investigations.

Retention Policies

Traces are verbose. A single agent query might generate 5-20KB of trace data. At 10,000 queries/day, that's 50-200MB/day, or 1.5-6GB/month. Manageable, but it adds up.

Recommended retention strategy:

• Hot storage (full detail, 7 days): Keep all spans, all metadata, all input/output text. This is your debugging window.
• Warm storage (aggregated, 90 days): Keep span trees and metadata, but drop full prompt/completion text. Replace with summaries or hashes. This is your trend analysis window.
• Cold storage (metrics only, 1 year): Keep only aggregated metrics: cost, latency, error counts, model usage. This is your capacity planning window.
• Special retention: Keep error traces and traces with negative user feedback at full detail indefinitely. These are your most valuable debugging and training data.

Building Custom Dashboards

If you're using Grafana (which you should, because it's free and excellent), here are the panels for your agent observability dashboard:

1. Top row: Four stat panels showing current error rate, p50 latency, average cost per query, and total traces in the last hour
2. Second row: Time series of error rate and latency (p50, p95, p99) over the last 24 hours
3. Third row: Bar chart of cost by model, pie chart of tool usage distribution
4. Fourth row: Table of recent error traces (linked to trace viewer), table of most expensive traces
5. Bottom row: Cache hit rate over time, turns-per-query distribution histogram

The Meta-Problem: Observability of Your Observability

There's a delicious irony in building observability for AI agents: the observability system itself needs monitoring. If your trace collector goes down, you lose visibility at the exact moment you need it most (because something is probably going wrong).

Practical measures:

• Health checks: Monitor your trace collector's uptime independently of the traces it collects. A simple HTTP health check endpoint, monitored by an external service (UptimeRobot, Pingdom), is sufficient.
• Queue depth monitoring: If you're using a batch span processor (and you should be, for performance), monitor the queue depth. A growing queue means you're producing traces faster than you can export them.
• Sampling fallback: If trace export fails, don't lose the data silently. Fall back to writing spans to a local file that can be replayed later. Better to have a big log file than no traces.
• Separate critical path: Your trace export should never block your agent's response path. Use async export with a bounded queue. If the queue is full, drop spans (with a counter metric), don't slow down the agent.

Putting It All Together: Your First Week

If you're starting from zero, here's a practical one-week plan to go from no observability to a production-grade setup:

1. Day 1: Add the basic trace decorator (Module 4, Pattern 1) to your agent's LLM calls. Deploy. You now have latency and cost visibility.
2. Day 2: Add tool call tracing (Pattern 2). Deploy. You now have full span trees.
3. Day 3: Set up a trace backend. If SaaS: sign up for Braintrust or LangSmith, add their SDK. If self-hosted: pip install arize-phoenix and phoenix serve. Export your spans.
4. Day 4: Build the trace analyzer (Module 5). Add it as a post-processing step. Log anomalies to your team's Slack channel.
5. Day 5: Set up the monitoring class (Module 6). Create a Grafana dashboard (or use your trace tool's built-in dashboard) with the golden signals.
6. Day 6: Run the cost analyzer (Module 7) on your first week of data. Identify the top 10 most expensive traces. Fix the obvious wins (loops, model routing).
7. Day 7: Write documentation for your team. Add alerting rules. Celebrate: you've gone from black box to glass box in one week.