Earlier in this series the examples had a knowable shape. "i want to rightsize my iam roles" resolves to an app — a packaged workflow that already knows the steps, because the steps are the same every time: find unused permissions, rank by blast radius, draft policies. A recipe exists, and an app encodes it.
But a lot of real security work has no recipe. "Find the root cause of these alerts" has no fixed sequence, because the third step depends on what the second one turned up. You can't write that workflow in advance. You have to investigate — form a hypothesis, pull a thread, and let the answer to each question decide the next one.
That's the class of problem this post is about. You still only say the outcome. What changes is that under the hood there's no pipeline being replayed — there's a model reasoning, branching, and deciding what to look at next.
Investigations, not workflows
For these, transiliencectl doesn't just match your intent to one app and run it.
It plans: it forms a working theory, calls whatever apps and queries test that
theory, reads the results, revises, and keeps going until it can either answer you
or act. It might run one app twenty times against twenty leads, or three different
apps in an order it only discovers midway through. The sequence isn't yours to
write, and it isn't the app author's either — it's derived live, from evidence.
A few that look small to ask and are large to answer:
"look at my alerts and find the root cause"
You have forty alerts and a feeling they're not forty problems.
transiliencectl run -q "look at my alerts and find the root cause"
The agent clusters the alerts that are really one event, builds a timeline, and walks backward through causality — this alert fired because that service degraded, which degraded because of a config change an hour earlier. It separates cause from symptom, which a severity sort can't do, because it follows the dependency chain instead of the noise. It doesn't know the chain until it pulls the thread; that's why there's no app that could have pre-encoded it.
"find the right path to remediate these CVEs"
A scanner handed you two hundred CVEs. The list is not a plan — most aren't reachable in your environment, some can't be patched without breaking a dependency, and a couple are quietly the only ones that matter.
transiliencectl run -q "find the right path to remediate this batch of CVEs"
The agent reasons past the CVSS score: which of these are actually exposed, which have an exploit in the wild, what each patch depends on, and what a fix might break downstream. Then it sequences a remediation path — patch order, not a ranking — so that fixing one doesn't reopen another. The output is the route, with the reasoning for each step attached.
"conduct a pentest and fix what you find"
The interesting vulnerabilities are rarely a single critical finding. They're two low-severity weaknesses that chain into one real one — the thing a list of individual findings will never show you.
transiliencectl run -q "conduct a pentest of our exposed services and fix what you find"
The agent reasons about attack paths: it looks for where a foothold could lead, chains weaknesses that are harmless alone and serious together, and traces how far each path actually reaches. Then it proposes the fixes, applies the ones you approve, and re-runs the same analysis to confirm the path is closed — an investigate-fix-verify loop, not a one-shot report.
"is this alert a real incident or just noise?"
The expensive part of an alert isn't responding to it — it's deciding whether to.
transiliencectl run -q "is this alert a real incident or just noise?"
The agent gathers context the alert itself doesn't carry: is this behavior normal for this principal, does it line up with a known change or deploy, does it fit a benign pattern or an attack one. It reasons toward a judgment — real, or noise, and why — instead of handing you raw signal to triage yourself.
"trace how someone could reach our production database"
You can list every control in front of the crown jewels. You can't easily see the one path that goes around all of them.
transiliencectl run -q "trace how someone could reach our production database"
The agent works backward from the target through the graph of identities, network paths, and trust relationships, chaining the small misconfigurations into a route an attacker could actually walk. The value is the path you didn't know existed — which only falls out of reasoning over the whole graph, not checking any single control.
What makes these different
The simple intents earlier in the series are answered by recall: an app knows the recipe, and running it is a matter of execution. These are answered by reasoning: there is no recipe, so the agent has to discover the path — and the path is most of the value. Root cause, the chain that makes a pentest finding real, the route to the database: in each, the steps weren't knowable until the investigation produced them.
And they still leave a trail. Because every probe the agent ran is a command, the investigation is reproducible end to end — you can see exactly how it reached its conclusion, hand that to an auditor, or re-run it and watch it land in the same place. A conclusion you can't retrace is a hunch; a conclusion you can is a finding.
You only ever said the outcome. The work of getting there — including working out what "there" even required — is the part that moved. The next posts get into how the agent plans an investigation like these, and what it's like to watch one reason in real time and steer it as it goes.
