You've built your career thinking in procedures. Step by step. First check this, then investigate that. Document, escalate, remediate.
That procedural thinking served you well when you were the one executing. But now you're working with AI agents—and that old mindset is holding you back.
In this lesson, we'll explore the declarative mindset: describing what you want instead of how to get it. We'll look at why it works better with AI agents, when to use it, and when not to.
The Problem With Steps
When most security practitioners start working with agents, they instinctively write instructions like this:
1. Open the SIEM and run query X
2. Filter results by timestamp
3. Export to CSV
4. Parse the IP addresses
5. Check each against threat intel
6. Flag any matchesThis is imperative thinking. You're spelling out every step.
It works great when you're the one doing the work. But when you hand these instructions to an AI agent, you run into problems.
The query syntax might have changed. The export format might differ. The threat intel API might return data differently than you expected. Your steps assume a specific state of the world—and the world changes.
There's a better way.
Describe the Outcome
Instead of dictating steps, describe what you want to be true when the work is done:
Identify any external IPs in yesterday's authentication
logs that appear in our threat intelligence feeds.
Return a list with the IP, hit count, and threat category.Same goal. No steps.
The agent figures out how. It finds the right data source. It chooses the right query. It handles the API calls. You just told it what.
This is declarative thinking.
Why Declarative Works Better
The Agent Sees What You Can't
When you dictate steps, you constrain the agent to your approach. But the agent can see the entire environment. It might find a better solution than the one you had in mind.
A colleague of mine spent 20 minutes writing detailed instructions for correlating firewall logs with authentication events. The agent followed them perfectly—and missed half the relevant data. Why? Because there was a second log source she didn't know about.
Had she just described the outcome ("find all authentication attempts from IPs that were later blocked by the firewall"), the agent might have discovered and used both sources.
Steps Go Stale
Your detailed instructions assume:
- Tools work the way you remember
- Data is structured a certain way
- APIs haven't changed
If anything differs, imperative instructions break. Declarative goals adapt.
Context Is Precious
Detailed steps consume tokens in the agent's context window. Space that could be used for actual reasoning gets filled with "run query X with parameters Y."
Worse, the agent can't verify your steps are correct. It just executes them. If the query syntax changed last month, the agent has no way to know.
The Spectrum
Instructions fall on a spectrum from purely imperative to purely declarative:
Micromanaging: "Click File, then Save As, then select PDF format, then name it report.pdf, then click Save." You're dictating every keystroke. The agent has zero autonomy.
Step-by-step: "Export the report as PDF. Email it to the stakeholders. Archive the original." Still procedural, but at least each step is a meaningful action rather than a UI interaction.
Goal-oriented: "Get the weekly report to stakeholders in a format they can review offline." Now the agent can decide: PDF? Email or Slack? Which stakeholders? It has room to adapt.
Outcome-only: "Stakeholders should have what they need for Monday's meeting." Maximum flexibility—but perhaps too vague. The agent might not know what "what they need" actually means.
The sweet spot is usually goal-oriented: specific enough to be actionable, flexible enough for the agent to choose its approach.
Before and After
Theory only takes you so far. Let's look at real security tasks and see how the same goal can be expressed imperatively versus declaratively.
Triage Task
Alert triage is bread and butter for SOC analysts—and a perfect candidate for agent assistance. Here's how most people instinctively write triage instructions versus the declarative alternative.
Imperative (avoid):
Open the alert in Splunk. Copy the source IP.
Run it through VirusTotal. Check AbuseIPDB.
Look up the ASN. Document findings in the ticket.Declarative (prefer):
Enrich this alert with threat intelligence context.
I need to know: Is this IP known-bad? What's its
reputation? What organization owns it? Summarize
findings so I can decide on escalation.Why declarative wins:
- Agent uses whatever threat intel sources are available
- Agent chooses the most relevant enrichment data
- Agent can adapt if one source is down or rate-limited
Detection Development
Writing detection rules involves technical details—file paths, field names, syntax, log sources. When you dictate all of this, you're assuming you remember it perfectly. The agent might actually know your patterns better than you do.
Imperative (avoid):
1. Create a new file detections/lateral_movement.yml
2. Write a Sigma rule with these fields...
3. Set the log source to windows/security
4. Add the detection logic for Event ID 4624
5. Include the filter for logon type 3Declarative (prefer):
Build a detection for lateral movement via network
logons. Should catch remote interactive sessions
from non-admin workstations. Follow our existing
Sigma rule patterns and include test cases.Why declarative wins:
- Agent follows your existing patterns (which you might not remember exactly)
- Agent handles the technical details (field names, syntax, file locations)
- Agent writes tests that match your testing approach
Automation Workflow
Building automation is where imperative thinking becomes especially limiting. You're not just executing a task—you're designing a system. If you dictate the exact flow, you might miss better architectures the agent could suggest.
Imperative (avoid):
Parse the email headers. Extract sender IP.
Check if IP is internal. If external, query
threat intel. If score > 7, create ticket.
Set priority based on score. Assign to tier 2.Declarative (prefer):
Build a triage workflow for suspicious emails.
External senders with bad reputation should
auto-escalate to tier 2. Internal senders just
need logging. Include appropriate context in
any tickets created.Why declarative wins:
- Agent might see a better workflow structure
- Agent handles edge cases you didn't think of
- Agent can verify the workflow actually works
When Imperative Makes Sense
Declarative isn't always better. There are legitimate situations where spelling out the steps is exactly what you need.
Learning the craft. "Walk me through this step by step so I understand." You want to see the process, not just the result.
Compliance requirements. "Use exactly this evidence collection procedure." Legal or regulatory requirements might mandate a specific approach.
Correcting mistakes. "No, specifically query X because Y." The agent tried something and got it wrong. Now you're steering.
Known-good procedures. "Use this exact playbook because it's been validated." You have institutional knowledge the agent doesn't.
The key is conscious choice, not habit.
A Template That Works
Declarative doesn't mean vague. A well-crafted declarative instruction gives the agent everything it needs to succeed while leaving the how open. Here's a four-part structure that works consistently:
Goal: What should be true when this is done? This is the north star—the outcome that defines success.
Context: Why does this matter? What's the background? Agents make better decisions when they understand the bigger picture.
Constraints: What boundaries exist? What should be avoided? Guardrails prevent the agent from finding a "creative" solution that breaks something important.
Verification: How do we confirm it worked? Defining success criteria upfront keeps both you and the agent honest.
Here's an example:
GOAL
Automate initial triage of phishing reports.
CONTEXT
Currently manual process taking 15 min per report.
Analysts spend most time on obvious spam that
could be auto-closed.
CONSTRAINTS
- Never auto-close reports from executives
- Preserve all evidence before any actions
- Follow existing escalation thresholds
- Log all decisions for audit trail
VERIFICATION
- Process 10 sample reports correctly
- No false negatives on known-malicious samples
- Audit log captures all decision points
The Mental Shift
This isn't just a technique. It's a different way of thinking about work.
When you think imperatively, you're the analyst and the automator. You design the solution, then spell out every step.
When you think declaratively, you're the analyst. The agent is the automator. You describe what needs to happen. The agent figures out how to make it happen.
This requires trust. You have to believe the agent can find a good path—maybe better than the one you would have chosen.
It also requires clarity. Vague goals produce vague results. "Improve our detections" isn't declarative; it's lazy. Good declarative instructions are specific about outcomes while being flexible about methods.
Key Takeaways
Declarative describes WHAT. Imperative describes HOW. When working with agents, focus on what.
Agents excel at figuring out HOW. They can see the whole environment. They can try multiple approaches. Let them.
Goal-oriented is the sweet spot. Specific enough to act on, flexible enough to adapt.
Include verification criteria. How do you know it worked? Test cases? Manual validation? Define success.
Choose consciously. Sometimes imperative is right. Make it a choice, not a habit.
Start Practicing
Next time you're about to write step-by-step instructions for an AI agent, pause.
Ask yourself: "What do I actually want to be true when this is done?"
Write that instead.
You might be surprised how much better the results are—and how much less work you have to do.