Thanks to increasingly capable models, some parts of your business are getting faster, more capable, and more productive every month. These teams are using artificial intelligence to compress timelines, surface insights, and automate work that has historically been time-consuming and tedious.

Meanwhile, other functions just down the hall are still waiting for a formal rollout, a governance approval, or someone to tell them what to do and how to start. The gap between the AI haves and have-nots in your organization is widening, and addressing it requires a new operating model.

Your teams need more support

When leaders notice the uneven distribution of capability across their business, the instinct is to treat it as a tooling problem. They push to get everyone access to the same platforms, provide general-use training, and hire some specialists to slot into IT.

But access is table stakes. It’s a good start, but it won’t get you to strong organizational adoption.

Harvard Business School reports that workers using these tools completed tasks 25% faster and produced results rated more than 40% higher in quality. But the same study also found that performance declined when people used the tools without understanding where they applied and where they didn’t. Fluency, not just access, drives results.

Departmental leaders need guidance on how to apply capabilities in the context of their day-to-day work. Without that knowledge, they can’t ask the right questions.

“Performance declined when people used the tools without understanding where they applied and where they didn’t. Fluency, not just access, drives results.”

Teams playing catch-up tend to focus on how to inject new tools into existing workflows, when they should be thinking about re-engineering processes entirely. They’re focused on evolution in a world undergoing revolution.

Reimagining a process also requires stepping back from it, which is easier said than done. Here’s how it plays out in practice:

An SDR team comes to IT with a specific, bounded ask: “improve our sales lead routing.” Completely reasonable. But only when someone from IT, with visibility across the broader system, dives into the problem does the real opportunity surface. The data pipeline supporting lead routing is unnecessarily complex. With the right support, the conversation shifts to overhauling the entire pipeline and opens the door to fully agentic lead follow-ups.

Departmental leaders don’t lack ambition but throwing a software license and Slack channel at them won’t build the right kind of adoption. Technical support and strategic guidance are required to reimagine work from first principles.

AI fluency must be a structural consideration

The typical pattern puts a centralized team in charge of taking requirements, interpreting them in isolation, and delivering capabilities to departments months later. This model can’t keep pace when AI capabilities launch weekly.

A more effective approach pairs a central “hub” that owns platform strategy, governance, and reusable patterns with AI engineers embedded directly inside business departments. AI engineers serve as “spokes” inside departments, helping them identify vertical use cases day-to-day and delivering the cross-functional visibility needed to make a real impact. The AI engineer who solved a problem for finance can share the pattern with someone facing the same challenge in operations.

“A more effective approach pairs a central “hub” with AI engineers embedded directly inside business departments.”

In a department just getting started, the embedded AI engineer is the primary technical capability: scouting, prototyping, building. In a more mature department, they shift toward enablement, feeding patterns back to the “hub” and helping teams navigate AI without getting buried in process. Over time, departments will organically become AI-fluent as they learn from the engineers.

Make fluency your advantage

The right operating model drives how a function actually works, and strong fluency strengthens processes and institutional knowledge, so outcomes improve over time. As the flywheel builds, each problem solved raises the ceiling of what your team can do independently. 

McKinsey finds that the right workflow redesign is the single biggest factor in whether an enterprise sees meaningful bottom-line impact. Knowing what to redesign depends on how your teams understand and work with AI.

Everyone is adopting AI capabilities. The question now is whether your operating model helps your teams see the best path forward for applying them. If it doesn’t, that’s the gap to close first.

The post Your organization prioritized AI adoption, but you actually need AI fluency. appeared first on The New Stack.

Security teams are discovering that the most capable AI models cost too much to run on routine, high-volume work, and they’re finding that out after the first invoice arrives. I lead a security operations team, and I’ve brought detection costs down to roughly $1 per day for trust and safety work. 

That number surprises people, because enterprise AI is supposed to be expensive. It isn’t, if you design the work correctly. The teams burning through budget are skipping the design work that determines which cases should reach a model at all.

The funnel is the cost lever

Detection funneling isn’t new. Before LLMs, security teams built layered filters to narrow high-volume event streams down to the cases worth a human analyst’s time. The same logic applies to AI spend. The narrower and more precise the funnel feeding your models, the lower your cost per accurate outcome.

“The narrower and more precise the funnel feeding your models, the lower your cost per accurate outcome.”

In trust and safety, most abuse is identifiable before any model runs. Deterministic, rules-based pattern detection captures a significant portion of volume upfront. Account age, email provider, and behavioral signals all feed automated filters that resolve the obvious cases and narrow what remains. Only the subset that clears those filters reaches an LLM. That’s where the dollar-a-day figure comes from. A well-designed funnel keeps expensive work to a minimum.

Think of it like a home security system. You don’t need a camera monitoring everyone who walks past your house. You care once someone’s actually inside, and that’s when you bring in the higher capability response.

Tiered models, tiered cost

For cases that clear the initial funnel, a lightweight model handles the first pass. The output is structured — a determination of malicious or benign at high or low confidence. High-confidence outcomes resolve automatically, while low-confidence cases escalate to a more capable model with broader context and stronger reasoning.

Only a fraction of events reach that second tier. We ran structured efficacy testing across model options and found only a 1-2% difference in accuracy between lightweight and frontier models for our use cases. Frontier models cost roughly five times more per token. That math only works if the cases reaching them need that capability.

Prompt engineering matters as much as model selection. One prompt I wrote for agentic detections runs over 1,900 words, covering every scenario the agent is likely to encounter, including when to escalate and when to act autonomously. Not every case needs that depth. Some trust and safety prompts are two or three sentences, but the scope of what you’re asking an agent to handle determines the precision the prompt requires.

“Frontier models cost roughly five times more per token. That math only works if the cases reaching them need that capability.”

Context is what separates accurate AI analysis from hallucination. Give a model an abuse report and ask whether the user is abusive, and it may take the report at face value. Give it the actual artifact being reported, along with the report, and it can independently assess whether the claim holds up.

Where humans still belong

Automation handles the clear cases. It’s the ambiguous ones that need judgment that agents don’t yet have.

Distinguishing a legitimate security researcher who hosts malware samples for analysis from a malicious actor who hosts the same content to target others requires discernment that AI still struggles with. So does a dispute in an issue thread where the terms of service could be interpreted differently. These cases reach a human because the question itself requires contextual reasoning the current generation of agents can’t reliably provide.

“Automation handles the clear cases. It’s the ambiguous ones that need judgment that agents don’t yet have.”

The goal is to give human reviewers the time to spend on the cases that actually need them. Instead of clicking through individual events, engineers on my team are building systems, writing prompts, and defining patterns that orchestrate detection at scale.

What this means in practice

Attackers try new obfuscation techniques, and we adapt prompts and models to catch them. It’s iterative work, closer in spirit to detection engineering than a one-time deployment. Prompt engineering is just another form of that: write the rule, test the output, tune when accuracy slips.

The cost question is solvable if you treat it as a design problem from the start. How much reaches a model, in what form, and with what context determines the bill. Most teams that find AI expensive haven’t made those decisions deliberately.

The post Tokenmaxxing is out. How to minimize AI spend without sacrificing security capability. appeared first on The New Stack.