Seventeen reports in. Eleven findings out. Every one owned.
Takes findings from every scanner, test and program, merges the duplicates, routes each to its owner, starts the SLO clock and drafts the routine fixes. People approve every change.
Watch it work
Northwind Outfitters
Findings from a code scanner, a dependency scanner, a penetration test, a bug bounty program and an AI red-team, tracked in the team’s bug tracker.
Demonstration. This shows how the SLO Velocity Agent works in your environment, run on a fictional company’s findings, tickets, code changes and team calendar. Open any ticket number to see what the agent read.
Watching the clock
In our experience, most findings don’t miss their SLO because the fix is hard. They miss it because the team is busy with its own roadmap, and no one asks in time. Waiting for an executive to escalate is not a plan.
- Found
Every finding gets a clock
A scanner, a penetration test or a bounty report. Severity sets the SLA, and no team is exempt.
- Assigned
To a team that is already busy
The owning team has a sprint full of feature work. The finding joins the queue.
- Stalls
Quietly
No bandwidth, an owner on leave, a vendor patch, a review no one picks up. Nobody says so until the date has passed.
- Pushed
Before the deadline
The program manager follows up while there is still time: reprioritize, reassign, fast-track. Agents show which findings are at risk, and why.
- Escalated
Only what must be
What still cannot make it reaches leadership with a decision attached: add people, accept the risk, or approve a compensating control.
- Fixed
Verified, then closed
The fix is retested, the clock stops, and the weekly on-SLO number says whether the process is working.
- S024 hours to fix · watched closely in the last 2
- S114 days to fix · watched closely in the last 5
- S256 days to fix · watched closely in the last 14
- The ticket
- Its status, comments and who it is assigned to.
- The linked change
- A review still waiting, checks failing, or merged but not yet deployed.
- The team calendar
- Who is out of office before the deadline, and who can cover.
- EscalateS0 with 2 hours left, waiting on a vendor
The fix needs a patched library the vendor has not shipped. The agent flags it; the program manager gets the security lead to approve a compensating control now, not after the clock runs out.
- ReassignThe owner is on leave past the deadline
The assignee’s calendar shows leave until after the S1 is due. The program manager hands it to a named teammate who knows the service, with the owner’s notes attached.
- Escalate“No capacity this sprint”
A comment on the ticket says the team cannot take it until next sprint, which ends after the SLO. The program manager takes it to the engineering manager this week, to swap it in for lower-priority work.
- Fast-trackA finished fix, stuck in review
The change has passed its checks and waited two days for a reviewer. The program manager asks for a priority review, so it ships in time.
Compared
Scanners find vulnerabilities, and vulnerability management platforms already collect and de-duplicate them. Here is what each does, and where an agent adds something new. In every column, people make the final call.
| What it does | By hand | Scanners and dashboards | Vulnerability management platforms | SLO Velocity Agent |
|---|---|---|---|---|
| Reads every source in its own format: scanners, penetration test reports, bug bounty, AI red-team results | Yesslowly | Notheir own findings | Partlystructured feeds | YesPDF reports too |
| Merges exact re-reports of the same issue | Yesslowly | Partlywithin one tool | Yes | Yesplain code |
| Recognizes the same flaw described differently by two sources | Yesslowly | No | Partlymatching rules | Yesand says why |
| Finds the owning team from code ownership and service maps | Yes | No | Partlyrules you maintain | Yes |
| Starts the clock at the first report from any source | Partly | No | Yes | Yes |
| Near a deadline, reads the ticket, its comments, the linked change and the assignee’s calendar | Yesa program manager, chasing | No | Nocounts days | Yesflags what will miss |
| Prices each finding in revenue at risk | No | No | Partlyrisk scores, not dollars | Yes |
| Drafts routine fixes such as dependency upgrades | Yesengineers | Partlydependency bots | Partly | Yesan engineer merges |
| A weekly brief with the decisions leadership needs to make | Yesslowly | No | Partlydashboards | Yes |
| Sets severity policy and accepts risk | Yespeople | Yespeople | Yespeople | Noleft to people |
● Yes◐ Partly— No
People’s hours a year, from report to fixed
84% fewer hours than by hand, and 74% fewer than with a platform and people: 1,007 hours, about $151K.
See the hours by activity, and how each is reached
| Activity | By hand | A platform and people | Agent and people |
|---|---|---|---|
| Read, de-duplicate and route reports17 reports a week, 52 weeks. By hand: 0.75 h each. Platform: about 0.4 h each, since rules catch exact duplicates but not the same flaw described two ways. Agent: 0.1 h each to check its work. | 663 h | 354 h | 88 h |
| Chase fixes near their deadline9 findings a week at 0.5 h each for a program manager to ask for status. A platform counts the days but someone still asks. The agent reads the ticket, change and calendar itself and flags only what will miss, which is counted in the brief. | 234 h | 234 h | 0 h |
| Draft routine fixes4 routine fixes a month. By hand: 3 h each. Dependency bots: 1 h each to review. Agent: 0.5 h each to review the draft. | 144 h | 48 h | 24 h |
| Write the weekly briefBy hand: 2 h a week. Platform: 1 h to turn dashboards into a brief. Agent: 0.5 h to check its brief. | 104 h | 52 h | 26 h |
| Decide severities, exceptions and escalationsThe same in every column: 1 h a week of people deciding. | 52 h | 52 h | 52 h |
| Total | 1,197 h | 740 h | 190 h |
Estimates for the fictional Northwind Outfitters at an assumed $150 an hour, on the same assumptions as the business case in the demo. Categories, not products: individual tools vary. Verify against your own environment.
How it works
- Intake
Every source, one shape
Scanner exports, penetration test reports, bug bounty submissions and AI red-team results, read in their own formats.
- Merge
Each issue exists once
Plain code merges exact re-reports. The agent recognizes the same flaw described differently by two sources, and says why.
- Route
Owner and clock
Code ownership and service maps decide the team. Your severity policy decides the SLO, and the clock starts at the first report from any source.
- Fix
Drafted, never merged
Routine fixes such as dependency upgrades arrive as drafts. An engineer reviews, tests and merges.
- Watch
Every fix against its clock
Close to a deadline (the last 2 hours of an S0’s 24, the last 5 days of an S1’s 14), the agent reads the ticket, its comments, the linked change and the assignee’s calendar. It flags what will delay the fix (an owner out of office, a vendor dependency, no capacity) and says what to do before the SLO is missed.
- Brief
One number, every week
On-SLO percentage, what is past due, what is due this week, and the decisions leadership needs to make.
Where it runs
- In your environment
- Next to your scanners and ticketing, with read-only access to sources.
- Your policy
- Severity rules, SLOs and exceptions are yours, written down.
- Into your tools
- Tickets in your tracker, drafts in your repositories, briefs where leadership reads.
- People approve
- Merges, severities and fixes are proposals until someone accepts them.
On your data
The demonstration above runs on a fictional company’s findings. On yours, the agent connects to your scanners, tests and ticketing, inside your environment. Design partners can pilot it on their own findings.
The engagement
SLO Velocity™Live in 2 weeks, then every day
- 1 · Week 1
Connect
- Agents
- Connected to your scanners, tests, tracker, repositories and calendars.
- Our people
- Deploy the agent and replay last month’s findings to check its merges and routing.
- Your people
- Grant read access and confirm owners.
- 2 · Week 2
Policy
- Agents
- Start the clock on every open finding.
- Our people
- Write the severity SLOs and the risk-acceptance path with you.
- Your people
- Approve the policy.
- 3 · Every week
Run
- Agents
- Merge, route, draft fixes, watch every clock, flag blockers.
- Our people
- Our program manager pushes before deadlines and prepares the decisions leadership has to make.
- Your people
- Engineers fix; leaders decide.
- 4 · From month 2
Hand over and watch
- Agents
- Keep running.
- Our people
- Train your program manager to run it, and check merge and routing accuracy monthly.
- Your people
- Own the weekly brief.
What agents don’t speed up: Your teams’ capacity. The agent makes it visible; people still have to make room.
What you keep
- SLO policy
- Severities, clocks and exceptions.
- Triage runbook
- What agents do, what people decide.
- Leadership brief
- One page, every week, with revenue at risk.
- Risk-acceptance path
- For what is accepted rather than fixed.
- Accuracy record
- Every verdict and every override, logged. Planted-answer scores on every run.
Tools find vulnerabilities. Programs close them. One intake, severity clocks and a weekly number took a payments platform’s backlog down by 98 percent.Large payments platform · Vulnerability management and governanceRead the case study
Questions
Which sources does it read?
Standard scanner formats such as SARIF and CSV exports, penetration test reports, bug bounty platforms and AI red-team results. New sources are a connector, not a rebuild.
What if the agent merges two different issues?
Every merge shows its reason and can be undone. Exact merges are mechanical; judgment merges are proposals.
Does it replace our ticketing system?
No. It feeds it: one clean ticket per issue, with owner, severity and due date.
How does it relate to SLO Velocity?
It is the engine of the program. The program sets the policy and the cadence; the agent keeps it running every day.