Turn runbooks into controlled execution.
Interactive Dox connects technical procedures to engineers, agents, scripts, APIs, and infrastructure actions, while keeping approvals and execution evidence visible.
Reduce repetitive operational work without turning every task into an autonomous AI action.
- ✓systemcheck service health · latency above threshold
- ✓scriptcollect recent logs · attached
- ✓AI agentsummarize the anomaly · summary ready
- ◐engineerapprove the restart · waiting for approval
- ·systemrun supported remediation · pending
production changes wait for an engineer
Automate the repeatable parts. Keep engineers at the decisions that matter.
Every runbook step goes to the right kind of executor. Deterministic checks and known actions run as software, AI helps where the signal is unclear, and engineers keep control of risky changes.
Automate deterministically
- API calls
- Scripts
- Environment checks
- Known remediation
- Data retrieval
Use AI selectively
- Interpret ambiguous logs
- Summarize findings
- Compare context
- Recommend the next action
Keep human control
- Risky changes
- Production approvals
- Exceptions
- Final judgment
From runbook to result, with an engineer at the decision.
Run the checks and known actions as software, bring in AI when the logs need interpreting, and hold production changes for an engineer's approval.
- 1Start the approved runbook for a degraded serviceRunbookstarted
- 2Check service healthSystemcompleted
- 3Collect recent logs and metricsScriptcompleted
Known symptom
4Match the symptom to a known remediationSystemmatchedUnfamiliar anomaly
5Interpret the anomaly in the logsAI agentnot this run- 6Recommend the next actionAI agentnot this run
Either way
7Approve the remediationOn-call engineerapproved- 8Execute the supported remediationSystemcompleted
- 9Capture the resultSystemrecorded
Records kept as the work progressesIllustrative workflow: degraded service runbook
Degraded service runbook
this run: a known symptom
- runbook started
- health check: latency above threshold
- logs and metrics collected
- known remediation matched
- engineer approval recorded
- supported remediation completed
- result and evidence captured
Generic labels. Which actions run depends on the scripts, APIs, and access you configure; production changes wait for an engineer.
What changes for the team?
01
Fewer repetitive manual steps
Checks, log collection, and known actions run as configured software.
02
Faster response
The runbook moves to the next step without waiting for someone to repeat routine work.
03
More consistent execution
Every run follows the approved runbook and its controls.
04
Clearer approvals
Production changes wait for a named engineer, and the decision is recorded.
05
Reusable evidence
Results, approvals, and exceptions stay with the run.
06
Controlled AI usage
AI works on the steps that need interpretation, not on every check.
Automate deterministically.Use AI when the signal is unclear.
Interactive Dox suggests where a script, an API call, or an existing utility can handle a runbook step instead of AI. Your team reviews the suggestion and keeps AI for the work that benefits from interpretation.
Controlled AI usage, not an autonomous operator.
Logs that are sent to a model still count as model usage. Remediation runs only through supported, configured actions.
- Current step
- Send every log bundle to an AI agent to decide whether the service is healthy.
- Suggested alternative
- Use a health-check API and threshold rules first, and bring in AI when the logs show something unfamiliar.
- Why consider it?
- Avoid unnecessary model processing on every run.
- Where AI may help
- Summarize an unfamiliar anomaly and compare it with earlier findings.
- Who chooses?
- Your engineers review the suggestion and approve risky changes.
- Known checkhealth API · threshold rule
- Unfamiliar anomalyAI summary
- Production changeengineer approval
Keep approvals and results with the run.
See which runbook ran, which executor handled each step, who approved the change, and what the result was, without rebuilding the timeline after the incident.
A completed run shows the configured steps ran. Checking whether the runbook still matches the environment is a separate validation.
Runbook run recordIllustrative workflow
Degraded service runbook
- Runbook
- Service degradation runbook
- Executors
- health API · script · AI agent · on-call engineer
- Approval
- restart approved · on-call engineer
- Remediation
- supported action completed
- Result
- latency back under threshold
recorded as the work progressed
- 02:14systemhealth check: latency above threshold
- 02:14scriptlogs and metrics collected
- 02:15AI agentanomaly summary attached
- 02:21engineerrestart approved
- 02:23systemremediation completed · result captured
Know the runbook still works.
A runbook is more useful when the team can see whether its supported steps still work against the environment it describes. For supported procedures, Interactive Dox validation checks the documented steps, tells you which step no longer matches, and drafts a revision for your team to review.
- ✓open the credentials vault
- ✓request rotation approval
- ✗step 3 · rotate and update the secret · field renamed on 3 June
- ·re-run the connection check
change detected · revision drafted for review
Verification runs where your systems already live.
A real check needs real systems and real credentials. For customer-hosted verification that is a reason to run it inside your environment, not a reason to send your environment somewhere else.
- Onboard a new vendorchecked last night
- Close the monthchecked last night
- Rotate database credentialsstep 3 changed · update waiting for review
- Provision a workspacechecked after yesterday's release
No inbound access required
Nothing has to be opened up to the internet, and anything typed into a secure field is dropped before step data leaves the machine.
You hear about changes first
When a step stops matching reality, your team is told, with the exact step, before a customer or a new hire follows it into a dead end.
Nothing changes without a person
A change becomes a drafted update. Someone on your team decides whether it becomes the current version.
IT & Engineering questions, answered.
Will AI act on production systems on its own?
No. AI agents interpret and recommend within their assigned steps. Remediation runs through supported, configured actions, and production changes wait for an engineer's approval where the workflow requires it.
Does every runbook step use AI?
No. Health checks, log collection, and known actions run as scripts, API calls, or other configured software. Interactive Dox suggests where AI adds value, and your team chooses how each step runs.
What does Interactive Dox verify?
Supported executable guides: runbooks and technical procedures that Interactive Dox can run against the real system they describe, on a schedule. When a step no longer matches, the team is told which step, a corrected revision is drafted, and a person decides whether it becomes current.
Where does verification run?
From the author's own machine through the desktop app (Run Now), or on a schedule through an agent you host. Private systems do not need to be reachable from the public internet.
Does Interactive Dox hold our production credentials?
Credentials used for verification are kept in the operating system's keychain on the machine that runs it, and anything typed into a secure field is masked before step data leaves that machine. The run result, step events and step screenshots, returns to the platform.
Bring one runbook. See it run with engineers in control.
Explore controlled execution with scripts, APIs, selective AI, and the approvals your team requires.
Book a demo around one real SOP.
Leave your work email and we'll follow up to arrange a demo built around one of your procedures.