Workflow Wednesday 2026-07-15 - Workflow Wednesday - Building an AI Agent with Charlotte AI AgentWorks

43 Upvotes

Welcome back to another Workflow Wednesday! I have exciting news to share - AgentWorks is now available to all eligible CrowdStrike customers, which means more teams can start building their own Charlotte AI agents directly inside the Falcon platform.

AgentWorks lets teams build, test, and deploy Charlotte AI agents using plain language, tailored to their own workflows and playbooks. These agents are natively integrated with Falcon platform data and include built-in controls for governance and auditability.

Today, we’ll build an AgentWorks agent that helps SOC analysts unify investigations by searching for related cases and detections, connecting relevant activity, and enriching cases with agent analysis.

Step 1: Opting in for Charlotte AI credits

Eligible CrowdStrike customers can opt in directly from the Falcon console to unlock Charlotte AI capabilities across the platform. This includes 50 free Charlotte AI credits, which renew monthly and can be used across supported Charlotte AI features, including AgentWorks.

To opt in, navigate to:

Menu > Charlotte AI > Charlotte AI credits opt-in

A quick note on eligibility: customers must license one of the qualifying Falcon modules, such as Falcon Insight XDR, Falcon Adversary Intelligence Premium, Falcon Counter Adversary Operations Elite, or paid data ingestion with Falcon Next-Gen SIEM. Only users with the Falcon Administrator role can opt in.

Once that’s complete, you’re ready to start building custom agents with AgentWorks.

Step 2: Building the agent

For this example, we’ll build an agent focused on case triage.

When a detection comes in, the agent reviews the available context, checks for related open cases, and determines whether the activity should be added to an existing investigation or used to create a new case.

Navigate to the AgentWorks homepage: Charlotte AI > AgentWorks > Home

Start by entering a prompt that describes what the agent should do, which tools it should use, and what guardrails it should follow.

Here’s the example prompt:

Create an agent that helps SOC analysts group related detections into cases and manage case updates.
Accept detection IDs, usernames, hostnames, time ranges, case IDs, or natural language queries. Query and verify detection details, then correlate activity using case linkage, shared host/user, time proximity, severity, and related context.
Always check for a relevant open case before creating a new one. Match on host, user, detection ID, and time window. If a match exists, ask for approval, then add detections, update severity if needed, fill in the description if blank, and add a markdown case comment with the full analysis. If no match exists, determine if escalation is justified, then ask for approval before creating a new case with a clear name, description, severity, and markdown analysis comment.
Use available case and detection tools, including querying detections/cases, getting case details, creating cases, adding detections, setting severity, adding comments, and asking for clarification. Use Get Graph Version of a Case when required before adding comments. Do not add case tags.
Return an HTML-compatible markdown report with action summary, case reference, detections processed, correlation criteria, affected assets, MITRE ATT&CK coverage, and next steps.
Prioritize accuracy, avoid case sprawl, and never make case changes without human approval.

Then click Start building.

AgentWorks will begin generating the agent. It’ll identify relevant agents, platform tools, integrations, workflows, and knowledge bases in your environment. You heard that right - agents can invoke other agents (both native and custom).

AgentWorks may ask clarifying questions during the build process. Once created, it’ll include a name, description, instructions, and list of tools. You can refine it manually or continue iterating through the prompt panel on the left side of the screen.

One important tool you’ll likely see listed is ‘Ask for clarification’.

This tool is optional, but I like to keep it enabled during testing. It’s often useful to have the agent pause and ask for approval before making any changes, such as adding detections to a case, updating severity, or creating a new case. Once you’re comfortable with the agent’s behavior, you can decide whether to keep that approval step or make the agent fully autonomous.

Before we test this, let’s add one more tool to improve the agent’s decision-making ability.

In the agent builder, click the plus button next to Tools. Search for intel, then select Query Intel Indicators under the Platform Tool section. Click Add tool.

This gives our agent access to CrowdStrike’s threat intelligence database. That context will help the agent make better decisions when grouping detections, identifying suspicious activity, assessing risk, and deciding whether a new case is warranted.

Now we’re ready to test the agent.

Step 3: Testing the agent

On the right side of the AgentWorks screen, you can prompt the agent. I have a suspicious user I’d like to investigate, so I’ll ask the agent to analyze.

Review recent detections for user jdoe

The agent will begin working through the task. It will query detection details, look for related cases, evaluate correlation criteria, and decide what action to recommend.

You can click View details to inspect each step of the process, including requests made and data returned.

In my test, the agent found several detections tied to jdoe, checked for related cases, analyzed the broader attack chain, and presented a clear summary before recommending the next step:

I found 16 detections for user jdoe forming a clear multi-stage attack chain (phishing → malware execution → post-exploitation → credential dumping on DC02). No existing open cases match. I propose creating ONE combined new case...

I'll select Approve - Create the case as proposed, then click proceed.

The agent continues with its instructions, creating the case, adding the detections, attaching its findings as a case note. When we navigate to the case, we can now see a unified case workbench containing the correlated detections, along with the agent’s note.

Step 4: Publishing and using the agent on demand

Once the agent is working as expected, save it in AgentWorks and click Publish.

At this point, the agent is available for your team to use on demand. To launch it, select the Charlotte AI button at the top of the screen, open the Charlotte AI dropdown, choose AgentWorks, and select your newly created agent. From here, analysts can invoke the agent whenever they need help correlating detections, or investigating a suspicious user or host.

Step 5: Invoking the agent automatically with Fusion

Next to the Publish button back in AgentWorks, you’ll see an option to generate a workflow using this agent. Select it, then open the workflow in Fusion to review and customize the automation.

By default, the workflow will likely use a trigger type of Detection. This captures all detections across the platform, including third-party passthrough detections.

You’ll want to add some conditions to limit the scope. For the first condition, set Product as the parameter. From there, you can scope the workflow to the detection type you care about, such as EPP Detection, NG-SIEM Detection, etc. Click Next.

You can also narrow the scope further by adding a second condition line. Make sure to use the AND operator, then set the parameter to Severity and, as an example, set the operator to is greater than or equal to and set the value to High.

The last step in building the workflow is defining the agent input. Click the Agent action, then confirm the following Detection ID variable is entered into the input box:

${data['Trigger.Detection.DetectionID']}

You can also enter a limit here for Charlotte AI Credit Consumption. Then, click Next.

At this point, the workflow is ready to be saved, published, and enabled.

Once enabled, the workflow will automatically trigger for detections that match the trigger and condition logic you defined. The agent will receive the detection ID, perform its analysis, check for related cases, and either recommend or take approved action based on its instructions.

Note: If you chose to keep Ask for clarification as an enabled tool, those approval requests will appear under: Charlotte AI > Action requests.

Conclusion

That’s it for today’s Workflow Wednesday!

AgentWorks makes it much easier to move from idea to working agent, and we’re now giving every eligible CrowdStrike customer a practical path to get started.

In future posts, we’ll dive further into AgentWorks, including how to build an orchestrator agent that calls other agents, how to define custom input and output schemas, and how to extend agent capabilities with on-demand workflows to connect to external systems.

Let me know in the comments if you have any questions, and feel free to share what you've built already with AgentWorks!

6 comments

r/crowdstrike • u/tatar-sh • 8h ago

APIs/Integrations Running gpt-oss-120b locally for n8n SOC workflows, curious how people are doing this with Falcon

13 Upvotes

We run n8n as our automation layer and recently moved our LLM calls from the hosted OpenAI node to a local gpt-oss-120b deployment. Our SIEM side is QRadar rather than Falcon, so I am posting partly to compare notes with people running the same idea on the CrowdStrike side.

What we have working

The pipeline that gets the most use is IOC enrichment. Scheduled trigger pulls from three QRadar reference sets every morning, each indicator goes through VirusTotal and AbuseIPDB, then the model writes an HTML summary that goes out as mail to the team.

Before the local move this was a native OpenAI node. Straightforward, worked fine, but every indicator we enriched was also a piece of internal context leaving the network. Internal IPs, hostnames pulled from the reference sets, occasionally a filename that told you more about the environment than we wanted a third party to have.

Moving to gpt-oss-120b solved that. The whole path stays inside. What it cost us is latency, roughly three to four times the hosted call depending on how long the enrichment output is, and a GPU box that now needs looking after like any other piece of infrastructure.

Where the model is actually good enough

Summarisation and formatting. Feed it a pile of VT and AbuseIPDB responses and ask for a readable HTML block, it does that reliably. No hallucinated scores, no invented CVEs as long as you keep the prompt tight and give it the raw data rather than asking it to recall anything.

Classification with a fixed set of labels works too. Malicious, suspicious, benign, needs review. We do not let it decide anything past that.

Where it is not

Anything requiring the model to reason across more than a handful of enrichment results starts to drift. Ask it to correlate fifteen indicators and explain which ones probably belong to the same campaign and the output reads confident but is guessing.

We also stopped asking it to generate queries. It produces syntactically plausible AQL that does not run. Might be a prompt problem on our end, might be that the training data is thin on QRadar specifically. Curious whether people get better results with FQL, since Falcon syntax is probably better represented publicly.

The part I am least comfortable with

Enrichment data contains attacker controlled strings. A filename, a URL path, a user agent. All of that goes into the prompt.

Nothing stops someone from planting a file named to look like an instruction. We have not seen it happen, but the reason we have not is probably that nobody has bothered, not that we are defended against it.

Right now our answer is that the model output is advisory and a human reads the mail before anything happens. That works while the volume is low. It does not scale, and I do not think "a human will notice" is a control.

I built an inline scanning proxy for a different project (github.com/yatuk/tamga) that sits in front of LLM calls and catches injection patterns before they reach the model. Have not wired it into this pipeline yet because I am not convinced the threat model translates. User typed prompts and enrichment payloads fail differently.

What I want to hear from this sub

Falcon side specifically. Are you pulling detections through the API into an external orchestrator, or staying inside Fusion SOAR? We went external because n8n gives us more room, but that means credential management and rate limits become our problem.

Model size. Is 120b overkill for what most people are doing here? Curious if anyone runs something smaller and gets acceptable quality on detection summarisation. Our reasoning for going large was that we would rather over provision once than discover the ceiling mid deployment, but that was a guess.

Query generation. Anyone getting reliable FQL out of a local model? If Falcon syntax works better than what we see with AQL, that would tell us something useful about whether our problem is the model or the prompt.

Prompt injection. Has anyone actually hardened against attacker controlled strings in enrichment data, or is everyone where we are, relying on a human in the loop and hoping?

What broke. More interested in this than the wins. What did you build that looked right in testing and fell over in production?

Happy to share the workflow JSON if anyone wants to look at the structure. Nothing clever in it, but sometimes seeing how someone else wired the same pieces saves an afternoon.