Example workflow you can build
From “can’t connect” to a reviewed firewall request.
An agent investigates the issue and prepares a change request. Your existing process authorizes and deploys any firewall change.
01 The problem
Your system
Our web application WEB01 can't reach prod DB02
Webhookstarts an oz0 job
02 The agent investigates
- Tool rules & approvals
- Model budgets
- Job history
Your task plugin
Runs on your oz0 node
Connector tool · Rule store
Querying: WEB01 → DB02, TCP 1433
Result: No openings found.
Connector tool · Host access
Your systems
- WEB01
- Firewall
- Production DB02
Result: Blocked
Connector tool · ServiceNow
"WEB01 cannot reach DB02. Should I request a firewall opening for your team?"
03 People decide
Your process · ServiceNow
The agent submits the request. Network and security owners decide in ServiceNow.
04 The outcome
Approved
Your systems
Applies the approved rule in its change window.
Agent repeats the test from WEB01 and updates the incident.
Denied
No team consent or change approval: stop.
Keep the findings in the incident.
Both possible outcomes are shown. No real actions run.
How these parts fit
- Plugin
- Installable package of agents, tools or instructions.
- Agent
- Uses your model to choose tool calls.
- Connector
- Plugin providing tools for an outside system.
- Tool
- Exposes actions the agent can call.
- Webhook
- Notification that starts configured work.
Use existing plugins or build these integrations. Plugin docs
Consent to request a change is separate from authorization to deploy it.
What you connect
Connect ServiceNow, approved firewall rules, firewall logs and deployment status. Provide a permitted execution tool on WEB01, through its oz0 node or authorized remote access.
Build an agentA starting point
net-diag provides read-only network checks. Ticket handling, rule lookup, server commands and change coordination need your integrations.
DocsThese starters are documented; publication varies. See oz0 Hub for availability.