Building AI agents is easy.
Building AI agents that consistently perform in complex environments, against adversaries that keep changing, is hard.
That gap is what led us to build Gamebooks.
We wanted security teams to direct and control the agents that investigate and respond in their environment. They own the environment, they understand its complexity, they own the security domain. They are the right people to decide how an investigation should run in their world.
The problem is that we can't let them tweak the actual prompt, or change the model, or change the tools. They are not AI engineers, and they shouldn't have to be. Optimizing an agentic flow, tuning the context window, knowing the failure modes of LLMs - the patterns that would make an LLM stupid, or vulnerable, or just stop working in certain cases - is a different craft.
So we want to empower security teams to customize and extend, deeply - without them destroying the quality and coverage of the AI underneath. That balance is the hard part, because it sits on the seam between two kinds of expertise that don't substitute for each other - security domain knowledge and AI engineering.
A game plan beats a script
A playbook is a script. No game ever follows the script.
Think about how a football team prepares. You do not script the entire game before kickoff. You can try. You can write down that on play 14, against one exact defensive formation, every player takes one exact route. Then the other team lines up differently. A player gets injured. The defense changes its coverage. The quarterback sees something unexpected. Your beautiful script is dead by the second play.
What actually wins is a game plan. A game plan defines what the team is trying to achieve, how to read the field, which options are available, and which rules must never be broken. It gives players room to adapt without letting everyone invent a different sport.
A SOAR playbook is the pre-written script. A Gamebook is the game plan. Three design principles let a game plan hold that balance.
Three design principles led the creation of Gamebooks
- Use anti-brittle, battle-tested building blocks (called capabilties). Instead of letting people rewrite prompts or rewire tools, teams build with building blocks we maintain and evaluate. A block like analyze email is generic to your stack and anti-brittle: if the email service is down when the agent calls it, the investigation isn't over - the agent finds another way to reach the same goal.
- Leave room for agent discretion. A lot of vendors let you build with AI, but when the flow actually runs, it's still if-this-then-that underneath. Those break. Adversaries study rigid rules and work around them. And with no adversary at all, reality breaks them - the same SOAR breakdowns we used to have and all hated.
- Enforce non-negotiable steps, and non-negotiable conditions. While the agent reasons freely, a Gamebook still enforces non-negotiable steps - and, more importantly, non-negotiable conditions: when the investigation moves on, when it keeps digging, when it can report a conclusion, and when it has earned enough trust to act.
A Gamebook is the control flow for the agent
A Gamebook is the control flow for the agent - controlled, not scripted. It defines:
- What must be investigated
- Which evidence must be established
- Which conditions should change the investigation
- Which actions are permitted
- When the agent must escalate, stop, or request approval
It describes investigative intent, not vendor-specific API calls. For example, a Gamebook may require Mate to establish how a suspicious file reached the endpoint, reconstruct its execution chain, determine whether it communicated externally, profile the affected user and device, and contain it if the evidence meets the organization's approved threshold.
That is very different from: call CrowdStrike endpoint 17, take the value from field 4, send it to VirusTotal, wait 30 seconds, and branch left if the score is above 5.
The first describes the security outcome. The second describes one implementation of that outcome, at one moment in time, using one specific stack.
Five layers run every investigation together
A Gamebook is not a standalone agent, and it is not a fixed workflow. It runs as part of an investigation architecture with five connected layers.
1. The orchestrator reads the investigation
When an alert arrives, Mate does not map one alert type to one workflow. The orchestrator examines the investigation context:
- Which product produced the signal
- Which users, endpoints, files, applications, and cloud resources are involved
- Which relationships already exist in the Security Context Graph
- Which other alerts or investigations may be connected
- Which Gamebooks are relevant to the situation
It may initiate one Gamebook or several. An endpoint alert might begin with the Endpoint Threat Investigation Gamebook. If the Graph reveals that the file arrived through a reported email, the orchestrator can also activate the Email Threat Investigation Gamebook. If the affected identity has unusual cloud activity, it can bring in the Cloud Identity Investigation Gamebook.
The investigation is composed around the situation in front of it. It is not locked to the label on the original alert.
2. Gamebooks define the investigation contract
Each Gamebook defines what the agents must establish and which boundaries they must respect. An Endpoint Threat Investigation Gamebook might require alert and entity extraction, user and endpoint profiling, process-chain reconstruction, file provenance analysis, file and network threat analysis, historical investigation context, and a final verdict with a confidence review.
The Gamebook gives the investigation structure and determinism. It does not dictate every query or every pivot in advance.
3. Capabilities do the investigative work
We call these reusable security skills capabilities - the battle-tested building blocks from principle one. (We use both terms; capabilities and building blocks are the same thing.) A capability is vendor-neutral:
- Profile a user
- Analyze a process chain
- Determine file provenance
- Analyze endpoint behavior
- Enrich a file hash
- Assess exposure
- Communicate with an end user
- Review the confidence of a verdict
- RDP to a machine
- Collect threat intel
The distinction matters. "Notify the user" is a capability. "Send a Slack message using this API call" is not. The capability describes what Mate needs to accomplish. The underlying execution may use Slack, Microsoft Teams, email, a service-management platform, or an internal tool.
Because capabilities are reusable, the same User Profiling capability can participate in an endpoint investigation, an identity investigation, a DLP investigation, or an email investigation. Mate ships with pre-built capabilities, maintains them, and composes teams of them inside different Gamebooks.
4. Agents investigate on the Security Context Graph
The agents executing capabilities do not work in isolation. They read from and write to the Security Context Graph.
One capability might extract a process, a file hash, and a user from the original alert. Another adds the process parent and child relationships. Another finds that the user recently received a suspicious email. Another retrieves a Memory explaining that this application is normally deployed through an approved IT process, but only on a specific group of machines.
Every result changes the investigation state. The next capability works from a richer Graph than the one before it. This is what lets agents pivot dynamically without losing coherence. They are not passing around disconnected blocks of text. They are collaborating on a shared, structured model of the investigation and the organization around it.
The Graph is the memory. The Gamebook is the control flow. The capabilities are the investigative abilities.
5. Flows reach the tools you run
A capability says what to accomplish - collect an endpoint profile. A Flow is how Mate gets it from the tools you actually run, whether that is CrowdStrike, Defender, SentinelOne, or an internal system. Mate builds and maintains these Flows, and your team can extend them for tools we don't cover.
Keeping the two separate is also what keeps the agent bounded. The Flow decides what can be queried or changed, so the agent can act without unrestricted access to everything.
Deterministic where it matters. Dynamic where it helps.
Underneath all five layers, one idea holds it together: the control flow is agentic. It is not deterministic, it is not rigid - but it is controlled.
This architecture separates two things security platforms have traditionally forced together.
The Gamebook is deterministic about intent. It defines what must be investigated, what evidence is required, which actions are permitted, and what approval boundaries apply.
The agent is dynamic about execution. It decides which capability to invoke next, which evidence to pursue, and when new context requires a pivot.
The Flow is deterministic about tool access. It defines exactly how systems can be queried or changed.
The Graph keeps everyone aligned. Every capability works from the same evolving investigation state and the same organizational memory.
That gives you flexibility without improvisation, and control without turning the agent into a ticket-routing bot.
When the world changes, the Gamebook holds
We recently migrated a customer's 711 playbooks into 10 Gamebooks, with much higher coverage. Fewer artifacts, broader coverage. The reason it consolidates like this becomes clear when something in the environment moves.
You swap your EDR. In a SOAR playbook, CrowdStrike APIs, response commands, field names, and assumptions may be spread across a dozen nodes. Moving to SentinelOne means rewriting the workflow. With a Gamebook, the investigation requirements do not change. You still profile the endpoint, reconstruct the process chain, retrieve the suspicious file, and assess its behavior. The relevant Flows change. The Gamebook does not need to be rebuilt.
You acquire a company with a different stack. The acquired environment may use different endpoint, identity, cloud, SIEM, and service-management products. A traditional playbook written for the parent company's stack transfers poorly, if at all. A Gamebook expresses the common investigative intent across both organizations. Each environment can use different Flows underneath it. Different infrastructure, same investigation logic.
A new alert type appears. Security teams rarely have a dedicated playbook for every signal their vendors release. With SOAR, no playbook usually means no automation. Mate decomposes the alert into its underlying entities, relationships, and behaviors, and the orchestrator activates the relevant pre-built Gamebooks and capabilities based on what the alert contains, not only on whether someone authored a workflow for its exact title. A new alert may still require new logic. But the team does not begin from an empty canvas every time a vendor adds another detection.
Your senior analyst leaves. Traditional playbooks preserve the steps, but often lose the reasoning. A threshold remains set to 5, but nobody remembers why it was 5 instead of 3 or 7. With Mate, investigation history, analyst decisions, relevant conditions, and their underlying reasoning are retained in the Security Context Graph. The Gamebook continues to use that organizational memory instead of depending on the person who originally built the workflow. The process survives. More importantly, the reason behind the process survives.
Consolidation like that has a second payoff, and it is strategic. Ten Gamebooks are something a security leader can reason about: what each one investigates, where it can act, and what it will never do. Seven hundred playbooks are not. Gamebooks adapt better to a changing adversary, and they are far simpler to understand and manage. When your automation is that legible, you can govern it - and governing your automation is a form of control too.
You build with it, not around it
There is a reason security teams care about the playbooks, detections, queries, and procedures they have built. Those assets contain years of hard-earned knowledge.
The problem is that traditional customization creates a fork. You start with a vendor template. You adapt it to your organization. The vendor keeps improving the original, but your version is now a separate branch that you maintain forever. The customization that made the product useful is also what stranded you from future improvements.
Gamebooks are designed around a different model. Mate ships and maintains pre-built Gamebooks, capabilities, and generic Flows. Your team can:
- Bring existing SOAR playbooks and translate their investigative intent
- Enrich generic Flows with internal systems and logic
- Build new Flows for proprietary tools
- Extend Gamebooks with organization-specific requirements
- Describe new investigation needs in natural language
- Test changes against previous investigations and known outcomes
- Require sign-off before sensitive actions are enabled
Your additions sit on top of a platform that keeps improving underneath them. You build with it, not around it.
Every investigation improves the next one
Gamebooks do more than execute investigations consistently. They participate in the larger detection-and-response loop - continuous detection and continuous response.
Every investigation adds evidence, relationships, outcomes, and reasoning to the Security Context Graph. Useful investigation patterns can become improved capabilities, updated Gamebooks, or new detections. Noisy detections can be tuned using actual investigation results rather than generic assumptions.
A detection is an investigation that has been repeated and compressed. An investigation is a detection that has not been compressed yet.
So the system does not only automate the current queue. It compounds. More investigations create better context. Better context produces more accurate investigations. Repeated investigation logic creates stronger detection coverage. Stronger coverage reduces noise and initiates better investigations.
From signatures to game plans
We moved from antivirus to EDR because static signatures could not keep up with a dynamic environment. Investigation and response never made the same jump. SOAR gave us programmable scripts, but scripts still assume the world they were written for will stay true. Unbounded AI gives us adaptability, but adaptability without structure is hard to trust with access to your environment and the power to act.
Gamebooks are the third option. The orchestrator composes the right procedures. Gamebooks define investigative intent and boundaries. Capabilities give agents reusable security abilities. Agents reason and pivot on the Security Context Graph. Flows execute safely against your tools. And every completed investigation improves what happens next.
You cannot script the whole game. You give the agents a game plan, let them read the field, and hold every move inside the rules.
That is the balance we were after: agents robust enough to trust with an investigation, and controlled enough to trust with a decision.
