The Deterministic–Agentic Spectrum in Campaign Analytics

AI product design is often framed too simply.

On one side, there are deterministic systems: tightly controlled, repeatable, and reliable. On the other side, there are agentic systems: flexible, adaptive, and capable of exploring many possible paths.

The real design question is not which side to choose.

It is where a specific task belongs on the Deterministic–Agentic Spectrum.

That is the principle I used when thinking about Campaign Analytics and, ultimately, when designing Azulens.

Agency should increase with ambiguity. Determinism should increase with the cost of being wrong.

That idea sounds simple, but it has major implications for how an AI-enabled analytics product should actually be built.

The false binary: deterministic vs. agentic

The current AI discussion often treats determinism and agency as competing product philosophies.

Either you build tightly controlled software, or you build an agent that reasons its way through the task.

I think that is the wrong abstraction.

Some tasks have one objectively correct or reproducible answer. Others contain ambiguity and benefit from exploration. Many real business workflows contain both.

• A payroll calculation should not creatively reason about the result.
• A permissions system should not improvise.
• A KPI formula should produce the same output when given the same inputs.

But research, troubleshooting, strategy exploration, or hypothesis generation often have no single predetermined path.

Those tasks benefit from more agency.

The interesting design space sits between those extremes.

The Deterministic–Agentic Spectrum

I think of this as a spectrum rather than a binary choice.

At one end are highly deterministic tasks:

• calculations
• permissions
• payroll
• metric definitions
• KPI formulas
• business-rule enforcement

Further along the spectrum are hybrid workflows:

• structured reporting
• campaign analytics
• compliance or claims workflows
• operational diagnostics

Then come more exploratory tasks:

• research
• discovery
• troubleshooting
• hypothesis generation
• strategy exploration

At the far end are highly open-ended autonomous agents that decide both what to do and how to do it.

The point is not that one side is better.

The point is that different tasks justify different degrees of agency.

One workflow can span multiple points on the spectrum

This became especially important to me while building Azulens.

It would be tempting to place “Campaign Analytics” somewhere in the middle of the spectrum and call it a hybrid workflow.

But that is still too simplistic.

A single Campaign Analytics workflow can contain tasks at very different points on the spectrum.

Highly deterministic

Examples include:

• KPI formulas
• campaign mappings
• metric definitions
• budget pacing calculations
• cross-channel aggregation
• reporting calculations
• threshold checks
• experiment calculations
• incrementality statistics

These do not become better simply because an LLM is given more freedom.

In many cases, they become less reliable.

Selective AI around a deterministic core

Other tasks benefit from reasoning around the calculated result:

• deciding which anomaly deserves attention
• interpreting patterns
• prioritizing evidence
• connecting multiple signals
• generating insights
• explaining what changed and why it may matter

More agentic

And some tasks are inherently more open-ended:

• generating hypotheses
• investigating an unfamiliar performance problem
• exploring strategy alternatives
• researching possible explanations

This leads to one of the central architectural ideas behind Azulens:

Campaign Analytics contains tasks across the spectrum, so I designed Azulens to assign different levels of agency to different tasks.

The analytical workflow does not need one fixed level of autonomy.

The system should be able to move along the spectrum depending on what the individual task requires.

Why Campaign Analytics is a useful example

A lot of Campaign Analytics is fundamentally deterministic.

That is important to state clearly.

KPI monitoring does not need an LLM to calculate the KPI.

Budget pacing does not need AI to calculate how much budget has been spent relative to time elapsed.

Cross-channel reporting does not need AI to add up spend or apply a metric definition.

Incrementality analysis should not rely on a model improvising the statistical method each time.

The analytical core is often deterministic.

Intelligence adds value around that core.

For example:

• KPI monitoring is deterministic; deciding whether a movement is meaningful and explaining it can benefit from AI.
• Budget pacing math is deterministic; prioritizing which deviation matters most and explaining likely causes may benefit from AI.
• Cross-channel calculations are deterministic; recognizing an important pattern across channels and generating hypotheses can benefit from AI.
• Incrementality design and analysis should be structured and reproducible; AI can help interpret the result and communicate it in business language.

That distinction is fundamental.

Many analytics tasks do not need AI to perform the analysis itself. They need AI around the analysis - to understand intent, prioritize evidence, recognize less predefined patterns and communicate what the result means.

That is also why I kept coming back to another principle:

I did not want the LLM to own the analytical truth. I wanted it to add intelligence around it.

What 12 years of Campaign Analytics taught me

I have spent roughly twelve years working with Campaign Analytics in practice.

One thing becomes obvious after doing this work repeatedly:

Daily analytics does not consist of completely new analytical problems every morning.

• The details change
• The campaigns change
• The clients change
• The channels change

But the classes of analytical work repeat.

Again and again, teams need to:

• create recurring reporting
• diagnose KPI movements
• recognize important patterns
• check budget pacing
• compare channels
• run performance reviews
• generate insights
• execute client-specific analytical workflows

The same analytical thinking gets applied repeatedly.

That led to a product question:

Why should either the user or an LLM have to recreate that analytical process from scratch every time?

If the same class of analysis has been performed hundreds of times, there is value in encoding that experience into the product.

That became one of the most important Azulens product decisions:

Turn recurring analytical processes into reusable Analytics Skills.

Turning recurring analytical processes into Verified Analytics Skills

A Verified Analytics Skill is not just a saved prompt.

It represents a reusable analytical process.

Depending on the workflow, it can contain:

• deterministic calculations
• defined inputs
• data requirements
• validation steps
• business rules
• structured context
• analytical sequencing
• selective AI reasoning
• explanation logic

The balance differs from Skill to Skill.

• A pacing Skill may be mostly deterministic.
• A performance-diagnostics Skill may begin with deterministic checks, then use AI to prioritize patterns and formulate explanations.
• A reporting Skill may rely on fixed calculations and structures while using AI to summarize the most important changes.
• A custom client workflow may combine predefined business logic with selective reasoning.

The goal is not to eliminate flexibility. It is to place flexibility where it adds value.

That is why my preferred framing is:

Deterministic where correctness matters. AI where reasoning adds value.

And at the interaction level:

Flexible intent. Controlled analytics.

How Azulens applies different levels of agency

The broader Azulens architecture follows the same principle.

At a high level, it consists of:

• Access & Automation
• Verified Analytics Skills
• Campaign & Measurement Context
• Managed Governed Data + Semantic Layer
• Data Sources

The important point is not simply that these layers exist.

It is that each layer has a different relationship with determinism and agency.

Data transformations, mappings, metric definitions, validation and calculations should generally be tightly controlled.

Intent interpretation, pattern recognition and explanation can allow more reasoning.

Open-ended investigation can allow more agency still.

The architecture gives those responsibilities somewhere explicit to live.

Different interfaces, one controlled analytics runtime

This also changes how I think about the interface.

Azulens can expose analytics through:

• Azulens UI
• Ready-to-run Analytics
• Conversational Analytics
• Alerts
• Automation
• APIs
• MCP
• Potentially a customer's own preferred LLM

These interfaces can be very different. The underlying analytical truth should not be.

Different interfaces. One controlled analytics runtime.

A user might execute a Performance Diagnostics Skill directly.

An alert might execute it automatically.

A user might ask a natural-language question that resolves to the same Skill.

An API or MCP client may call that capability from another system.

In the future, a customer may prefer a different LLM entirely.

The interface and model can change without forcing the analytical process itself to change.

That is strategically important to me.

Models can change. Analytical truth should not have to.

This is why I prefer:

Open interfaces, controlled execution.

MCP is an access layer. An API is an access layer. A conversational interface is an access layer.

They should not each reinvent the analytics architecture.

Flexible intent, controlled analytics

Natural language is still extremely useful.

A user should be able to ask:

Why did performance deteriorate last week?

But flexibility at the interface does not require unconstrained execution underneath.

A controlled flow can look like this:

1. Interpret intent.
2. Match or compose the relevant Analytics Skill.
3. Resolve parameters and context.
4. Execute the analytical process.
5. Explain the result.

The same Skill could also run every morning without a conversational interaction at all.

That is why I think the phrase captures the architecture well:

Flexible intent. Controlled analytics.

The user can remain flexible.

The analytics do not need to become arbitrary.

Managed data and explicit business context

There is another important lesson behind this architecture:

Good analytics is not just an LLM problem. It is also a data and modeling problem.

Azulens therefore includes a Managed Governed Data + Semantic Layer underneath the Analytics Skills.

That means continuously handling work such as:

• Connectors and custom data sources
• Transformation
• Field mapping
• Metric definitions
• Validation
• Data quality checks
• Freshness monitoring
• Maintenance

This work is especially important when the data landscape includes not only standard advertising APIs but also:

• CRM
• POS
• Offline sales
• Spreadsheets
• Email-delivered reports
• Custom client systems

A warehouse does not make this work disappear.

A semantic-layer technology does not make this work disappear.

Someone still needs to model, validate, maintain and understand the data.

For Azulens, that capability is part of the product.

Context should also be explicit

Data alone is not enough.

Analytics also depends on business context:

• Campaigns
• Strategies
• Objectives
• KPIs
• Targets
• Learnings
• Measurement structures

My view is increasingly:

If context repeatedly influences business decisions, it is often worth modeling explicitly.

The alternative is asking the model to infer the same context over and over again from prompts and fragmented information.

That is usually a weaker architecture.

Incrementality as one example of explicit context

Incrementality is a useful example, but it is only one example.

A Lift Study can exist as a dedicated Measurement Context object linked to a Master Campaign.

It can explicitly define things such as:

• Treatment and Control arms
• Experimental units
• Treatment logic
• Time or geo assignments
• Outcome definitions
• Duration
• Commercially relevant lift
• Target iROAS
• Approved test design

The analytical method should not have to reconstruct those structures from an ad hoc prompt every time.

Once the Lift Study exists, Analytics Skills can operate on it to:

• Validate execution
• Check mappings
• Monitor treatment contrast
• Identify deviations
• Run the statistical analysis
• Calculate incremental revenue and iROAS
• Quantify uncertainty
• Explain the result

This illustrates a broader point:

Some AI problems are not primarily prompting problems. They are modeling problems.

If something repeatedly matters to the decision, it may deserve to exist as a structured object in the system.

Why this architecture fits smaller teams particularly well

I think this architecture can be especially valuable for smaller teams.

Not because smaller teams need less sophisticated analytics.

Often the opposite is true.

A relatively small marketing organization may still operate:

• Meta
• Google
• Amazon
• CRM
• Offline sales
• Spreadsheets
• Custom data sources

But it may not have:

• Data engineers
• Analytics engineers
• A BI team
• Data scientists
• An internal AI team

The analytical requirements can be complex even when the organization is small.

What is missing is often the infrastructure and specialist capacity required to maintain that complexity internally.

This changes how I think about the value proposition.

Small teams do not necessarily need more analytical freedom. They often need more analytical infrastructure delivered as a product.

That infrastructure includes more than AI.

It includes:

• Managed data
• Metric definitions
• Mappings
• Validation
• Context
• Recurring analytical workflows
• Analytical logic
• Monitoring
• Explanation

In other words, the value is the packaged analytical capability underneath the interface.

A smaller team may derive more value from a reliable predefined diagnostic workflow than from being given a blank agent and being asked to design the analysis through prompting.

The smaller the analytics team, the more valuable predefined intelligence can become.

That does not mean rigid software.

It means that accumulated analytical experience can be embedded in the product instead of requiring every customer to rebuild the capability internally.

What I deliberately gave up

There are trade-offs to this architecture.

It is not the right answer for every AI problem.

By choosing reusable Analytics Skills and controlled execution, I deliberately give up some of the flexibility of a fully autonomous agent.

That means:

• Not every completely new question is automatically covered
• A new analytical class may require composition of existing Skills
• Sometimes a genuinely new Skill needs to be designed
• Analytics Skills require product and engineering work to build, verify and maintain
• The system is less open-ended than simply giving a powerful model broad access and asking it to solve whatever comes next

There are tasks where that trade-off would be undesirable.

For highly exploratory research, discovery, or open-ended investigation, a more agentic architecture may be the better choice.

I would not use the Azulens architecture as a universal template for every AI application.

For daily Campaign Analytics, however, the trade-off is intentional.

I am deliberately trading some open-ended flexibility for repeatability, reliability and operational efficiency.

That brings benefits that matter in recurring analytical work:

• Consistency
• Reproducibility
• Transparency
• Reliability
• Lower cognitive load
• Faster execution
• Easier automation

The user does not need to invent a good analytical prompt every Monday morning.

The analytical process is already there.

What building Azulens taught me about Applied AI

Building Azulens has changed how I think about Applied AI architecture more broadly.

Four lessons stand out.

Learning 1 - Maximum agency is not the goal

A lot of AI product development implicitly treats more autonomy as progress.

I no longer think that is a useful default.

The goal is not to give the model as much freedom as possible. It is to give it as much freedom as the task benefits from.

If the task has a reproducible answer and the cost of error is high, extra agency can be a liability.

If the task is ambiguous and exploratory, more agency may create substantial value.

The architecture should reflect the difference.

Learning 2 - Model important context instead of repeatedly inferring it

Campaigns, strategies, KPIs, objectives, targets and Lift Studies are examples of information that repeatedly influences analytical decisions.

If the system needs the same context again and again, relying exclusively on inference is inefficient and fragile.

If context repeatedly influences business decisions, it is often worth modeling explicitly.

This reduces ambiguity and gives both deterministic software and AI reasoning a better foundation.

Learning 3 - Repetition is a product opportunity

Twelve years of Campaign Analytics taught me that repeated analytical behavior is not boring.

It is valuable product information.

When users repeatedly ask the same classes of questions, that repetition reveals where analytical knowledge can be productized.

Recurring analytical behavior is a signal that the process should become a reusable product capability.

That is the logic behind Verified Analytics Skills.

Instead of treating repetition as something the model should solve again, it becomes an opportunity to make the system better.

Learning 4 - Applied AI architecture is about boundaries

Many of the hardest design questions are not about the model itself.

They are about boundaries.

• What should the model decide?
• What should deterministic software decide?
• What context should be modeled explicitly?
• What data should the model see?
• What authority should it receive?
• Where should outputs be reproducible?
• Where is exploration acceptable?

Applied AI architecture is largely about deciding where uncertainty belongs.

That is the deeper meaning of the Deterministic–Agentic Spectrum for me.

Return to the spectrum

I started with a simple principle:

Agency should increase with ambiguity. Determinism should increase with the cost of being wrong.

After building around that idea, I no longer think of Campaign Analytics as one deterministic or agentic problem.

It is a collection of tasks across the spectrum.

• Some should be highly deterministic.
• Some benefit from selective AI reasoning.
• Some are genuinely exploratory.

The architecture should recognize those differences instead of forcing every task into the same execution model.

That is what I tried to do with Azulens.

• Turn recurring analytical experience into reusable capabilities.
• Keep data and analytical logic governed.
• Model important context explicitly.
• Use AI where it actually improves the result.
• Allow different interfaces and models to access the same analytical foundation.

And keep the core principle simple:

Deterministic where correctness matters. AI where reasoning adds value.

Or, from the user's perspective:

Flexible intent. Controlled analytics.