There is a subtle shift happening in how we design incident response systems.
For years, most solutions followed a deterministic (explicit, rule-based, structured) model. An alert fires, a playbook runs, actions execute in a defined order, and results are returned. When something breaks, we trace the path, fix the logic, and run it again.
That model still works. It works extremely well in security operations where consistency, auditability, and control are required.
I ran into this while designing an orchestration workflow using an Azure Function. The approach was straightforward. Take a question, generate KQL, run it, retry on failure, and return results.
At the same time, I started exploring agent capabilities in Azure AI Foundry. That is when it clicked. I was designing the exact path instead of defining the objective and letting the system determine how to get there.
This is what people are calling agentic logic.
This is not about replacing automation. It is about understanding how these models differ and where each fits.
Quick context: Foundry, Functions, and Logic Apps
Before going deeper, it helps to align on roles.
Azure AI Foundry provides a managed agent runtime and private LLM hosting. You define instructions, tools, and constraints, and the system handles reasoning and execution flow.
Logic Apps are a low-code workflow platform built around connectors, abstracting much of the complexity of working with APIs.
Azure Functions take a code-first approach, offering more flexibility and control at the cost of more explicit implementation.
A simple way to think about it:
- Agents decide
- Functions and Logic Apps execute
Agents can replace some orchestration patterns, especially those centered on interpretation and dynamic decisions. They do not replace structured workflows that require strict control or reliability.
The structured mindset
At its core, structured logic is if/then control flow. If a condition is true, an action is taken. If it is not, an alternate path is followed. That simple pattern scales into most of what we build.
You see it everywhere:
- If severity is high, enrich entities
- If an IP is external, run a lookup
- If confidence is high, update the incident
This works because it is predictable, testable, and easy to audit. Given the same input, you expect the same result every time.
Where structured systems start to strain
The problem is not the logic itself. It is the environment it operates in.
Security data does not stay still. Schemas evolve, logs change shape, APIs shift, and alerts often arrive incomplete. Over time, structured workflows accumulate assumptions about how things should look.
Those assumptions drift.
The result is familiar:
- Workflows expand to handle edge cases
- Logic becomes harder to follow
- Failures occur when data does not match expectations
The system still behaves exactly as designed, but it is no longer aligned with reality.
What agentic logic actually means
Agentic logic shifts the model from step-driven execution to goal-driven behavior.
Instead of defining every step, you define:
- The objective
- The tools available
- The constraints
The system determines how to proceed.
In practice, that often looks like:
- Interpreting a request
- Deciding what data is needed
- Generating and running queries
- Evaluating results and refining the approach
You are not removing control. You are relocating it into boundaries and constraints instead of explicit steps.
One important clarification is that agentic systems are not unstructured.
Most are built around a loop that is still defined in code. The system interprets input, selects an action, executes it, evaluates the result, and repeats until it reaches a stopping condition. That loop often includes guardrails such as retry limits, allowed tools, and exit conditions.
What changes is not the presence of structure, but where it lives.
In structured systems, the developer defines the exact path step by step. In agentic systems, the developer defines the loop and the boundaries, and the system determines the path within them.
Foundry agents vs external orchestration
The distinction becomes clearer when you compare approaches.
With a Function or Logic App, you own the flow. You define sequence, retries, branching, and failure handling. Execution is explicit and predictable.
With a Foundry agent, you define the objective and let the system determine how to achieve it. It selects tools, evaluates intermediate results, and adapts as it goes.
Foundry also brings built-in capabilities:
- Context and state handling
- Integrated tool usage
- Tracing and telemetry
- Managed deployment and identity
This leads to a natural separation:
- The agent determines what should happen
- The workflow ensures it happens reliably
Example: KQL investigation
Consider a simple KQL scenario.
In a structured approach, the system generates a query, runs it, retries if needed, and returns results. Every step is predefined.
In an agentic approach, the system interprets the question, decides whether schema context is needed, generates a query, evaluates the result, and refines if necessary.
The steps are similar. The difference is who controls the flow.
Tradeoff: adaptability vs predictability
Structured systems are designed to produce the same result every time.
Agentic systems do not:
- Outputs may vary
- Behavior can shift with model updates
- Execution paths are dynamic
At the same time, agentic systems can still be:
- Auditable
- Governed
- Consistent in outcome
The tradeoff is clear. Structured systems optimize for predictability. Agentic systems optimize for adaptability.
Observability and Sentinel integration
As systems become more dynamic, observability becomes critical.
Azure AI Foundry provides tracing across:
- Inputs and outputs
- Tool usage
- Execution steps
- Token and latency metrics
Much of this is already captured through Azure Monitor via Application Insights, giving you a strong baseline without additional work.
This telemetry can be routed through Log Analytics and integrated into Microsoft Sentinel, allowing agent activity to be monitored and investigated alongside other security signals.
When more control is needed, you can extend this by:
- Writing structured logs to a custom table
- Capturing key decisions and actions through tools or functions
- Including logging expectations directly in agent instructions
This creates a layered model, combining built-in telemetry with purpose-built SOC logging where it matters most.
Cost considerations
Cost per model call is the same. The difference is usage.
Structured workflows tend to have fixed, predictable calls. Agent-based workflows may take multiple steps and carry more context, increasing total usage.
In most incident response scenarios, the difference is negligible. At scale, it becomes worth measuring directly.
Practical guidance
A forward-leaning approach is to start with agentic design and introduce structured control where needed.
Focus on:
- Strong guardrails in tools and code
- Comprehensive logging and tracing
- Feedback loops from analysts and users
- Periodic review of system behavior
If strict repeatability, compliance requirements, or predictable cost at scale become necessary, shifting back to a structured approach is a deliberate design decision.
Closing thought
This is not a choice between two models.
It is a shift in how we design systems.
Structured logic provides precision and control.
Agentic logic provides adaptability.
The most effective solutions will combine both, applying each where it makes the most sense.
I will be sharing a practical example of how this comes together, including logging, tracing, and Sentinel integration, in a follow-up post.
Previously, I demonstrated a deterministic approach to AI Operated SOC using Foundry AI. Building on this we will discuss Sentinel MCP and soon AI Operated Agentic SOC.