How to measure what AI actually saves, account for agent swarms, and budget for secure operations.
An AI subscription shows up on an invoice. The time your team spends correcting its output usually doesn’t.
Neither does the effort to connect it to your business systems, investigate a failed run, or unwind a change it should never have made.
That makes AI easy to underprice in a business case. You can know exactly what the model costs and still have no idea what it costs to finish the job.
For leaders deciding where to invest, the useful unit is a completed business outcome: an invoice processed correctly, a support case resolved, or a report someone can use without rebuilding it.
Why This Matters
Measure AI by cost per accepted outcome, with quality and safety requirements defined before the test. Include human review, integration, failed attempts, and ongoing operations. When multiple agents coordinate the work, count the entire team’s consumption and permissions. The same techniques that help legitimate teams work faster are also being adopted by attackers, making identity controls and incident readiness part of the operating budget.
Cheaper intelligence still needs a business case
OpenAI’s GPT-6.1 Terra announcement describes lower standard API prices than its predecessor. Lower model prices can make useful workflows economical that previously weren’t.
They don’t tell you what your workflow will cost.
An agent may read the same material repeatedly, call paid tools, retry a failed step, ask other agents for help, and produce something that still needs human correction. A cheaper model can become more expensive if those additional steps outweigh the price difference. A more capable model can justify its price if it reliably reduces them. Neither result should be assumed.
I would evaluate an AI workflow using a Cost of Accepted Work calculation:
Cost per accepted outcome = total attributable workflow cost ÷ outcomes that meet the agreed acceptance criteria.
Use the same measurement period and workload for both sides. Include the costs of failed and abandoned attempts in the numerator. Count only accepted results in the denominator.
The cost ledger should cover:
- Model usage, software subscriptions, paid tools, and infrastructure.
- Data preparation, integration, testing, and employee enablement, allocated over an explicit period and realistic volume.
- Human review, exceptions, corrections, and manual fallback.
- Monitoring, access controls, support, and maintenance.
Track quality, turnaround time, and security failures alongside the number. A workflow that is cheap because it skips required checks has failed the comparison.
Keep uncertain incident exposure in a separate risk assessment. Include the cost of prevention and response readiness in the operating plan, but don’t invent a precise expected-loss number to make the spreadsheet look complete.
A simple example makes the difference visible
Consider this invoice-processing workflow. These are illustrative assumptions, not customer results or a vendor benchmark.
Suppose manual processing takes 12 minutes per invoice at a fully loaded labor rate of $60 an hour. The labor cost is $12 per invoice.
Now suppose an AI-assisted process uses $0.20 in model and tool charges per invoice, averages four minutes of human review and exception handling, and carries $1.80 in allocated integration and operating costs. Assume every invoice is ultimately accepted, and these per-invoice averages include all retries, corrections, and manual fallback.
The AI-assisted cost is $6 per accepted invoice: $0.20 in usage, $4 in human time, and $1.80 in allocated costs.
That is a meaningful improvement. It is also very different from comparing $12 of labor with $0.20 of AI usage. This simplified example compares manual labor with the listed AI-assisted costs. For a scale decision, apply the same cost categories and allocation rules to both processes.
Then ask what happens to the recovered time. If employees use it to clear a backlog, improve service, or absorb growth, that is capacity value. It becomes cash savings only when spending actually falls or a planned expense is avoided.
An honest business case can show both. It should not count the same benefit twice.
Agent swarms add speed, coordination, and cost
An AI agent uses a model and tools to work toward a goal. An agent swarm generally means multiple agents dividing work, coordinating tasks, and combining results. Implementations differ in how independently agents operate and how much a central coordinator controls them.
A research workflow might assign separate agents to different documents, then have another assemble the findings. Security teams can use coordinated agents for authorized investigation. Attackers can use similar coordination for reconnaissance and other parts of an intrusion.
So a swarm is not inherently malicious. Describing swarms as primarily cyberattack tools goes beyond the evidence. The legitimate uses also matter to the economics: Kimi’s Agent Swarm documentation describes parallel research and batch processing.
From a general AI agent swarm perspective, parallel work can finish sooner while consuming more total resources. Additional agents also create handoffs to inspect, outputs to reconcile, and permissions to manage.
My default would be to start with a simpler workflow and add agents only when testing shows a worthwhile improvement in quality, throughput, or elapsed time. If ordinary automation handles a deterministic step reliably, use it.
A second agent reviewing the first can help catch errors. It is not an independent authorization system, and agreement between agents is not proof that a business action is permitted.
The attacker use is real, even without full AI agent autonomy
The security concern deserves attention on its own terms.
In its October 21 report, Microsoft described Storm-0940’s use of ARTEX, a multi-agent penetration-testing framework, in a real attack campaign. That is observed threat activity, not simply a demonstration of what agents might do.
In a separate October 29 assessment, Microsoft reported North Korean threat actors adopting AI across reconnaissance, social engineering, software development, and other operational work. It also identified ARTEX use. Microsoft explicitly assessed those AI-enabled operations as still human-directed, rather than fully autonomous.
Those findings support a practical concern: attackers can use AI to accelerate familiar work. They do not establish that most agent swarms are malicious or that every phase of an observed attack ran without human involvement.
You don’t need a fully autonomous adversary to have a serious problem. Faster research, more tailored lures, and quicker abuse of existing access can put additional pressure on detection and response.
Organizations should distinguish two responsibilities:
Defend the business against attackers using AI. Keep patching, identity protection, endpoint controls, and incident response current. Review application identities and service accounts as well as employee logins. Investigate unusual app consent, credential changes, and resource access. Verify sensitive requests through trusted channels instead of relying on whether a message “sounds AI-generated.”
Protect the AI workflows you operate. Treat outside documents, messages, websites, and tool output as untrusted inputs. A malicious instruction hidden in that material should not be able to grant access or authorize a transaction. Restrict what agents can read, where they can send data, and which actions require approval.
Using AI for defense adds another decision: how much authority to give defensive agents. An agent that summarizes an alert needs different permissions from one that can disable an account or change a firewall rule. The label “security agent” doesn’t remove the need for authorization and rollback.
Budget for controls that work outside the prompt
NIST’s October 27 agent identity management design tenets provide a useful direction. They are proposed design guidance, not a new certification or a guarantee of security.
The guidance calls for distinct agent identities, limited delegated authority, short-lived and revocable access, human-review triggers, and separation of policy enforcement from model reasoning.
In practical terms, an agent should not be able to acquire broader permissions simply by creating a subagent. A prompt saying “don’t disclose sensitive data” should not be the only barrier preventing an export. Approval for one transaction should not silently become approval for the next.
A workable architecture separates the agent that proposes an action from the system that permits it. That system checks the identity, target, scope, and approval before execution. Logs connect the action to its initiating request and record the result. Operators need a tested way to revoke access and handle work already in progress.
All of that takes engineering and operating effort. Budgeting for it is more credible than presenting it later as an unexpected cost of production.
Your AI Pathfinder Action Plan
Before expanding an AI pilot, bring the workflow owner, finance, IT, and security together around one process.
- Define an accepted result. Specify accuracy, required evidence, turnaround, permitted data use, and the actions that need human approval. Name the person who accepts the work.
- Measure the current process. Capture labor time, exceptions, rework, volume, and quality. Include the difficult cases, not just the easy demo.
- Test the simplest viable design. Compare ordinary automation, a single agent, and a multi-agent approach only where each is relevant. Record the full workflow cost and human effort.
- Test failure and misuse. Include misleading inputs, unavailable tools, repeated failures, unauthorized requests, and attempted data disclosure. Confirm that access revocation stops subsequent actions and that escalation reaches a real owner.
- Make a scale decision. Review accepted-outcome cost, quality, elapsed time, and control failures. Set budgets for retries and agent creation. Assign ongoing support, incident response, and rollback responsibilities before production expansion.
A useful pilot can end with a decision not to scale. That is cheaper than discovering the problem after connecting the workflow to sensitive systems.
Where Netsync fits
This is the work between buying an AI tool and operating a dependable business process.
Netsync’s AI and automation services cover readiness and use-case prioritization, workload and data architecture, security integration, implementation, and ongoing operations. Those disciplines belong in the same discussion because a workflow’s economics depend on how it is built and supported.
We can also help implement AI security solutions to strengthen detection, access controls, and response to AI-enabled threats. No security solution eliminates every risk.
For an organization evaluating adoption, a useful starting point is one workflow with a measurable baseline, explicit data and action boundaries, and a named operating owner. That gives a readiness conversation something concrete to evaluate without assuming a particular platform or promising savings before testing.
Frequently Asked Questions
Does the cheapest model produce the cheapest work?
Sometimes. Test total workflow consumption, human correction, and acceptance rates. A higher-priced model may reduce retries, but that is a workload-specific result to measure.
Should businesses avoid agent swarms?
Not categorically. Use them when the benefit justifies the additional consumption and complexity. A malicious swarm and a legitimate agent team may use similar coordination techniques; intent, access, and enforcement determine the security implications.
Can we prove ROI by counting hours saved?
Hours are a useful input. Validate that the time was actually recovered, identify how it is being used, and distinguish capacity gains from reduced spending. Also account for the people reviewing and operating the system.
The Bottom Line
Before approving the next AI expansion, ask for one completed-work report: what the workflow finished, what people had to fix, what the whole process cost, and whether it stayed within its authority.
That report is a better investment guide than the model invoice alone.
Related reading: Gemini 4 Carbon vs. Claude and GPT: where Google wins and where it doesn’t.
About Jason Fleagle
Jason Fleagle is the Head of AI for Netsync and writes AI Pathfinder about practical AI adoption, business value, and secure operations. Explore more at netsync.com and thejasonfleagle.com.
Originally published on LinkedIn.
