What is Signal Engineering?

A new operating model for working with data, and the role that comes with it.

Last Tuesday, a director of digital marketing at a marketing agency opened Claude Desktop and typed something like this:

Generate an audience of households within a 30-mile radius of 1247 Auto Mall Drive, Lakeland FL 33815 showing intent for travel trailers, fifth wheels, or the brands Jayco, Winnebago, and Forest River. HHI above $75k. Exclude current RV owners. CSV formatted as Street Address, City, State, ZIP, Lat, Long. No PO Boxes, no apartments.

He watched an agent compose the audience against more than 100,000 raw signals on Watt's Reasoning Graph, downloaded the CSV, uploaded it to a DSP, and shipped the campaign before lunch.

In the old world, that request would have been a six-week project. Procurement would have evaluated which vendor's licenses covered RV-purchase intent at household-level resolution. A data engineer would have written a pipeline. A data platform engineer would have provisioned the warehouse and the serving infra. A data scientist would have engineered features and trained a propensity model. A data product manager would have wrapped the model in something the marketer could touch. The marketer would have filed a ticket and waited.

Five roles. Six weeks. One audience.

What the director did on Tuesday is not a faster version of that workflow. It is a different operating model entirely. The five-role chain that used to produce the answer has collapsed into one person plus a substrate. All five stages of it now happen in one person's session, against one searchable surface, in real time.

That person has a name now. They're a Signal Engineer. What they do is compose across raw signal, in real time, against a reasoning-time data substrate, in service of an outcome they own end-to-end. That work is Signal Engineering.

This post is about that operating model: what it replaces, what it involves, who does it, and why it had to exist now.

The operating model it replaces

For 20 years, anyone whose job depended on data they didn't produce was a Data Consumer. Marketers, analysts, founders, product engineers: same role, different titles. They waited on a five-role chain to produce their answer.

1. Procurement secured the upstream data licenses. Bespoke contracts, lawyer-heavy, often six-figure minimums per vendor, multi-quarter cycle times.
2. Data engineering wrote the pipelines that turned each vendor's bulk feeds into queryable rows.
3. Data platform operated the warehouses and serving infrastructure.
4. Data science engineered features from raw signal and trained models against them.
5. Data product wrapped those models in something the consumer could touch without writing SQL.

The Data Consumer's actual job was at the end of that chain. Their primary skill (the thing that got measured) was translating their question into a ticket precise enough that the chain could act on it. Then waiting. By the time the answer came back, it had been reshaped by every link: sized to capacity, scoped to the data already on hand, frozen at the moment of delivery. New question, new ticket.

This chain was unavoidable for any company that wanted to do something off-the-shelf vendors couldn't replicate. ZoomInfo and Apollo are finished retrieval products; they sell the same dozen fields to everyone. Anything more specific, the kind of differentiation a company actually competes on, required going upstream past the productized layer to raw signal the company could compose against on its own terms. And going upstream meant funding all five functions in sequence-then-parallel. Multi-quarter to multi-year from greenfield to first informed action. Seven-to-eight figures cumulative cost before the platform produced its first decision.

Most companies that needed this never built it. They couldn't afford it. The procurement gate alone stopped most attempts before engineering ever started. The ones that did build it found themselves locked into the questions they scoped at the beginning; every new class of question that didn't fit the original scope was another quarter-long project. The platform that was supposed to serve the consumer became a tax on their velocity.

What changed

Two things changed, in the same window.

1. The substrate became consumable by anyone. LLMs reason by composition: they evaluate how things are like or not like other things, across structured information, in real time. MCP gave them a clean protocol for calling external data and tooling. And the data infrastructure built specifically for that kind of consumer started to exist. We call it reasoning-time data: structured for traversal rather than for SQL. Watt's Reasoning Graph is one instance. The general class is the substrate AI systems compose against at inference: raw signal at the resolution events actually happened, exposed through composable operations the model authors in the prompt.
2. The five-role chain became one person plus the substrate. When the consumer of data is an agent, and the substrate is built for an agent to compose against, the operator at the end of the chain doesn't need the chain anymore. They describe the outcome they want. The agent composes the data work against the substrate. They sanity-check what came back. They ship. The work that used to be procurement plus engineering plus platform plus science plus product happens in one session, in one person's head, against one searchable surface.

That collapse is what Signal Engineering names. The role that emerges from it is the Signal Engineer: the operator, analyst, founder, or engineer who used to wait on the chain and now composes against the substrate themselves.

What a Signal Engineer actually does

Signal Engineering isn't a single move. It's a six-stage operating loop, and most of the leverage compounds in the last two.

1. Articulate the outcome. The Signal Engineer says what they're trying to achieve (the audience to reach, the question to answer, the decision to drive) in their own language, at whatever resolution they currently have. Precision is not the goal here; intent is. Most outcomes start fuzzy and sharpen through composition, so the work of this stage is less about specifying the answer and more about handing the substrate enough to start composing against.
2. Compose interactively. The Signal Engineer co-designs the data workflow with the substrate. They explore signals, push back, weight, combine, and watch the composition take shape across the conversation. This is exploratory data analysis collapsed into a chat, not pipeline construction. The substrate brings breadth. The operator brings depth: which signals actually represent the buyer, which combinations are spurious, which weights match how the market actually behaves. Neither produces the composition alone.
3. Vet the composition. Before pointing it at production, the Signal Engineer earns trust in what they've built, sanity-checking the result size, gut-checking against domain expectation, verifying against benchmarks, inspecting sample results, reviewing how signals are weighted. Trust is earned through inspection. Different compositions warrant different vetting; the operator decides what's enough.
4. Wire in feedback. Before going live, the Signal Engineer defines what counts as a good outcome and a bad one in production, and how those signals flow back as labeled data. Engagement, conversion, dwell time, reply rates, downstream business metrics. With feedback wired, yesterday's results become inputs to today's run, and the composition compounds without anyone in the loop. Skip this step and the work plateaus at whatever quality it shipped at. This is the stage that separates the Signal Engineers who plateau from the ones whose work keeps getting sharper, and it's the one most operators skip on the first pass.
5. Run in production. Wire the inputs: what triggers the composition (a timer, a prompt, an upstream agent call). Wire the outputs: where the results go (a CRM field, a destination file, a downstream agent, a UI surface). Deploy. In the legacy world this was a separate engineering project measured in weeks. In the new world it's a Signal Engineer task measured in minutes: a skill definition, a connector, a deployed agent.
6. Sharpen in production. Read what production is teaching you. Edit the composition based on what you see (eg, new signals that became available, patterns the original framing didn't anticipate, scope extending to a new geo or vertical, indirect coverage through proxy signals when the substrate doesn't have a direct one). The memory loop auto-compounds in the background; this stage is the structural work the loop can't do on its own.

The output of all six stages is a living system the operator owns end-to-end.

Three flavors of Signal Engineer

Signal Engineers come in three shapes, defined by what they produce from the substrate.

• The Data Operator uses data to create outcomes. Running campaigns, shipping audiences, sending sequences, routing leads, refreshing audiences against fresh signal. Composition is always in service of the play they're running today. The artifact is a repeatable workflow. Success is whether the action happened and whether it worked. Most Operators came up through digital, performance, lifecycle, or growth marketing; today the role also shows up as GTM Engineers, RevOps, MarTech, and lifecycle Ops.
• The Data Analyst analyzes data to reach a decision. ICP discovery, churn diagnosis, hypothesis validation, anomaly hunting, capability inventory. The artifact is an analysis (a finding, a recommendation, a discovered ICP.) Success is whether the answer is sharp enough to act on. Bad analysts produce work that gets read and ignored. Good ones produce work that changes what the org does next.
• The Agentic Builder ships a product to create outcomes. Where the Operator runs a play and the Analyst hands off a decision, the Builder ships infrastructure that runs the play or makes the decision repeatedly, autonomously, at scale. The artifact is an agent: code that runs in their stack, calls the substrate at reasoning time, and orchestrates signal into outcomes for someone else. Operator-prompted Claude Desktop is the prototype; the Builder's product is what replaces the operator in the loop.

All three operate the same way against the substrate. The composition surface is identical. What differs is what they ship.

What Signal Engineering is not

A useful negative space sharpens the term. The anti-persona is the Data Plumber, the operator whose craft is connecting existing data products to deliver them to the next step. Wiring ZoomInfo to Outreach. Enriching from Apollo through Clay into HubSpot. Gluing pre-finished outputs together with workflow tools and prompt chains.

The Plumber isn't lazy or unsophisticated. They're often very good at the connections. They're operating on an inherited assumption: that the differentiation lives above the data, in the cleverness of the assembly. That assumption is collapsing in real time. An AI engineer with Cursor can wire ten data vendors together in an afternoon. The thing that used to be a craft is becoming a commodity.

The defining question separates Plumbers from Signal Engineers cleanly:

The Data Plumber asks "what data can I get?" The Signal Engineer asks "what can I find?"

The difference is structural, not attitudinal. A Plumber's surface area is the union of their data subscriptions. They can only ship what their vendors sell, in the shape their vendors sell it. If a workflow depends on LinkedIn URL, the workflow is bounded by LinkedIn URL coverage. If the vendor doesn't carry "owns a 2019 Brinkley Model G," the Plumber doesn't ship that audience. The ceiling is the contract.

A Signal Engineer's surface area is the raw data itself. They blend across signals (intent, behavior, ownership, life-event, geography, demographics) and reason to the outcome. A Signal Engineer can land an audience on a 60%-coverage signal because they're composing it with eight others. The composition is the artifact; no single field has to carry the weight.

One operates inside the bounds of finished products. The other operates over raw signal and builds the product in the prompt.

Most operators arrive as Plumbers. That's not a flaw; it's the inheritance. A decade of Apollo, ZoomInfo, and Clearbit selling the dream that retrieval-plus-orchestration is enough has trained every GTM and AI tooling persona to think this way.

@Watt, the best part of the job is watching the flip happen. An operator shows up asking about match rates on a single field, gets walked through composing across thirty signals instead, and you can see the moment the constraint they didn't know they were operating under falls off. The shackles come off and the work gets bigger. That moment is the thesis of this entire post made real, one Signal Engineer at a time.

Why this matters

Signal Engineering isn't a feature, a tool, or a service offering. It's an operating model: what replaces the legacy data delivery cycle. The role that comes with it is what replaces the Data Consumer. Both are downstream of a structural shift that already happened. The consumer of data stopped being a human and became an AI agent, and the substrate built for that consumer became consumable by anyone with an idea.

The five-role chain doesn't go away because the work goes away. The work was always real. Audiences still have to be composed. Decisions still have to be defended. Agents still have to be wired. The chain goes away because all of that work now happens in one person's session against one substrate, in minutes instead of months, at a cost that's a rounding error against what the chain used to cost.

The companies that figure out how to operate this way are going to feel like force multipliers. The ones that don't are going to feel like they're filing tickets into a void.

This is the first in the Signal Engineering series. Future posts will cover what the best Signal Engineers do that the rest don't, how the three flavors of the role evolve as more of the loop closes autonomously, what the substrate underneath has to deliver to keep up, and how organizations restructure once Signal Engineering becomes the default operating model for working with data.

The shift is already happening.