Skip to main content
When your agent goes into production, the questions you care about are things like: did it get stuck, did the user give up, did this run fail for a different reason than last week’s. You can answer them by opening a trace and reading it. You can’t answer them across ten thousand traces. Signals are how Laminar answers them. A Signal is an instruction, written in plain language, that reads every trace and produces a structured record when it sees what you described. The result is a stream of events you can query, cluster, and alert on.
Signal detail view with events list and per-event payload

A Signal's events tab: each row is one detected event linked back to a trace

​
Signals read the whole trace, not the final answer

A Signal is not a grader pointed at your agent’s last LLM output. Every Signal reads the entire trace: every LLM turn, every tool call, every subagent, every retry, and every error, from the first span to the last. Most interesting failures in a long agent run are invisible from the output alone:
  • A tool returned an error in step 12 and the agent quietly worked around it. The final answer still reads as confident and complete.
  • The agent issued the same search three times with the same arguments. The answer is right and cost three times what it should have.
  • A subagent came back with nothing usable, and the parent filled the gap with a plausible substitute.
  • The agent violated a rule from its system prompt forty steps ago, and the only trace of it is a subtly wrong deliverable.
Scoring the last LLM span cannot see any of these, because by the time the agent writes its final message the evidence is dozens of spans upstream. Signals look there. That’s why a Signal can tell you which tool failed, what the agent did about it, and what the user ended up believing as a result, instead of just the answer looks fine.

​
Anatomy of a Signal

A Signal has three parts, and you configure all three:
  • Prompt: plain-language instructions describing what to detect or extract from a trace.
  • Structured output schema: a JSON schema the extracted payload must conform to. You name the fields you want pulled out of every match, which is what makes the resulting events filterable and queryable instead of a wall of prose.
  • Triggers: trace conditions that must be met for the Signal to run, so you’re not analyzing traces you don’t care about.
That’s everything. Laminar handles the rest.

​
A concrete example

Here are those parts on a real run, and the event they produced. A travel agent was asked to plan a trip and return a flight and a hotel with the nightly price. search_flights returned real results. get_hotel_availability returned upstream_timeout three times in a row. The agent then wrote a well-formatted itinerary containing three named hotels with nightly prices, none of which came from a tool result. The prompt describes the failure in plain language:
The output schema names three fields to extract for each occurrence: unsupported_claim, failed_tool, and user_impact. And this is the event Laminar produced on that trace:
Nothing in the agent’s final message says “the hotel API never answered.” To connect the fabricated prices back to the timeout, you have to read the tool result in the middle of the run, which is exactly what the Signal did. Now multiply that by every trace you produce. One row per occurrence, filterable by failed_tool, queryable in SQL, clustered with the other traces that failed the same way, and wired to an alert the next time it happens.

​
What else Signals can help you answer

The hotel example is one failure class. If you can describe it to a colleague, you can write a Signal for it.
  • Business outcomes: “agent completed checkout,” “agent answered the question correctly.”
  • Logical failures: “agent loops on the same tool without progress,” “agent gave up after one retry.”
  • Behavioral categorization: user intent, topic, any categorical field you want on the trace.
  • User friction: “user asked for the same information multiple times”, “user gave up after multiple retries”.
  • Cost and waste: “long context, short answer,” “tool called with malformed arguments and retried.”
Essentially, anything you’ve ever had to ask a teammate to skim traces for. If you’ve written a Slack message that starts with “can you look through today’s runs and tell me how often…”, that’s a Signal.

​
How a Signal run works

When a trace matches a Signal’s trigger conditions, Laminar doesn’t just paste the raw trace into a single LLM call. A Signal run is a small investigation, and it moves through three stages: compress the trace, let an agent investigate it, then turn what the agent found into events.
Chat GPT Image Jul 2, 2026, 05 33 30 PM

​
1. The trace is compressed

Agent traces are long. A single run can contain hundreds of spans, megabytes of tool output, and the same system prompt repeated on every LLM call. Before anything reads the trace, Laminar compresses it into a compact transcript:
  • LLM turns and tool calls are kept. These carry the story of what the agent did.
  • Repeated system prompts are deduplicated and summarized, so the transcript states them once instead of on every turn.
  • The user’s original request is extracted and placed up front, so the Signal always knows what the agent was asked to do.
  • Plumbing spans are dropped unless they carry errors or match the Signal’s relevance rules.
Traces are compressed to around 10% of it’s original token count on average
Compression is lossy on purpose, but nothing is out of reach: every span in the transcript keeps a short reference id, and the agent can use it to pull the full, uncompressed content of any span on demand.

​
2. An agent investigates the trace

Your prompt doesn’t run as a one-shot classification. Laminar runs it as an agent with tools, working over the compressed transcript across multiple steps:
  • It can search within span content to find where something happened.
  • It can fetch the full input and output of any span by its reference id when the compressed view isn’t enough.
  • When it has seen enough, it submits its findings and the run ends.
This is what makes Signals reliable on long traces. A checkout failure buried in step 40 of a 200-step run isn’t lost to truncation: the agent can search for it, pull the exact tool output, and base its answer on the actual content. A run ends in one of two ways:
  • The agent submits one or more findings. Each finding contains a payload that conforms to your schema, a short summary of what was found, and a severity (critical, warning, or info).
  • The agent submits nothing, meaning the behavior you described wasn’t present in that trace. No event is created.
A single trace can legitimately produce multiple findings: an agent that retried a broken tool three times produces three retry events, not one.

​
3. Findings become signal events

Each finding becomes a signal event linked back to the trace that produced it. From there, every event independently flows into the rest of the platform:
  • It’s indexed for search, so you can find it from the Signals UI.
  • It’s checked against your alert rules (severity and custom payload filters), and matching events fire Alerts.
  • It’s queued for clustering, where Laminar groups it with similar events from other traces so patterns surface as Clusters.
Signal events are accessible via the signal_events table and can be easily queried using the SQL Editor. All signal events are linked to the traces that produced them. You can use event payloads to query corresponding traces. In a sense, you can think of a signal event payload as an additional column of the traces table.

​
Run a Signal on new traces or historical traces

Each Signal can run in two modes, configured independently:
  • Triggers run the Signal on new traces as they arrive. Use Triggers for anything you want to watch in real time (live error rates, live success counts, anything that feeds Alerts). Trigger filters are AND-combined and are evaluated against accumulated trace state, so Signals fire once per matching trace.
  • Backfill runs the Signal across a historical slice of traces. Use a backfill to seed a new Signal, re-run a changed prompt over last week’s traffic, or investigate a window of traces that match a filter.
Both paths produce the same kind of signal event; the only difference is when and which traces the Signal reads.

​
Next steps

Quickstart

Write your first Signal, trigger it on new traces arriving in real-time, and see events.

Clusters

Learn how Laminar groups similar signal events so you can see patterns.

Alerts

Fire Slack or email notifications on new signal events or clusters.