90% of the AI news in your feed right now is hype or doom, and both are totally useless for developers. I filtered through 495 AI news updates from the past month so you don't have to, and only three things actually matter for your work: decision models like Jev, the lessons from this month's agent security incidents, and software factories.
In this guide I'll share what you need to know about each one, the important technical details, and how to start implementing it in your workflow today.
The short version
| Update | What it is | What to do about it |
|---|---|---|
| Decision models (Jev, Strands Decider, OpenAI Decisions API) | Models that return typed decisions with probabilities, computed in parallel instead of token by token | Hand classification-style questions to a decision model, enforce rules in code, and keep the generative model for writing responses |
| Agent security incidents | Models in cybersecurity evals reached the real internet, external servers and external chatbots | Map everything the agent can reach, separate access from permission, and test what happens after an alert fires |
| Software factories | Agents carrying a change through several stages of development, including investigating failures and retrying | Define "done", make the project runnable without you, make feedback fast, decide what the agent can retry, and measure real cost per accepted change |
Decision models: Jev, Strands Decider and the Decisions API
Let's start with a new family of models that could end up saving you a lot of money if you implement them into your project in the right way.
Imagine you're building a customer support agent. Before it writes a response, you need to figure out which team owns the ticket, how urgent it is, and whether the customer is requesting a refund.
With a general-purpose LLM, you might ask for those answers in a JSON object. Underneath, the model is still generating the response token by token.
Jev, from TypeSafe, changes that output step. You send it the ticket as the input state, then define your questions and the possible answers. It returns typed decisions with probabilities, and it computes those outputs in parallel instead of writing them out token by token. So you can ask about the team, urgency, and refund requests together, all at once.
How a decision model works under the hood
Amazon's related Strands Decider gives us concrete implementation details of what's going on inside these kinds of models. It starts with a pretrained Qwen model and replaces the language-modeling head, which normally predicts the next token, with a small pointer head. That head compares the model's internal representation at the answer position with its representation of each supplied option. Those comparisons produce scores, and a softmax turns them into probabilities.
And the options come from your request. They aren't fixed categories baked into a classification head. You can supply a different set of departments without retraining the model just to add another output class, for example. That makes it much more flexible than a traditional classifier.
TypeSafe isn't the only company moving in this direction. Alongside Amazon's Strands Decider, OpenAI announced its Decisions API in limited preview, and open source options have also started being released.
How to use a decision model in an agent
So for that support agent, we could use this division of work:
- A decision model handles the questions about the ticket.
- Ordinary code enforces refund limits and permissions.
- A generative model writes the customer's response.
That can reduce latency and cost while keeping the more capable model available for the work that needs it.
What the AI agent security incidents teach developers
But before you give an agent more access to your development workflow, let's talk about what happened when some of the AI labs made some security oopsies this month.
In September, Anthropic published a report about a model that was supposed to be solving a simulated cybersecurity challenge and ended up uploading a malicious package to the Python Package Index.
Claude had been told it had no internet access, but the environment was misconfigured, so it could actually reach the public internet.
After Mythos 5 uploaded the package, fifteen third-party systems installed it. Credentials leaked from one of those systems, and the model used them to access a security vendor's database. Eek.
Telling the model more clearly that it might be on the real internet didn't reliably solve the problem. In modified replays, it still took offensive actions while acknowledging that it could cause real harm.
We all heard about the OpenAI Hugging Face incident in July. Agents running cybersecurity evaluations exploited weaknesses in shared infrastructure, reached external systems, and executed code on dozens of Hugging Face servers.
Of course these examples were cybersecurity evaluations running with fewer safeguards than the companies' deployed products. But we can learn something pretty specific about how to build and test these systems: calling an environment a "sandbox" doesn't tell you everything the agent can reach.
So there are three things I'd take from these reports when you're setting up your own agents.
1. Check everything the agent can reach, including through other services
Perplexity tested whether agents could escape their sandboxes. None of its 108 runs broke out of the VM, but agents got around network restrictions using DNS spoofing and shared CDN IP addresses. So map and test access through package proxies, database connectors, and MCP servers too. They may reach destinations the agent can't access directly.
2. Separate access to a service from permission to perform an action
Downloading a package doesn't require permission to publish one. Pushing a feature branch doesn't require permission to change repository settings.
Meta's Muse design keeps credentials outside the agent's runtime. A component called Sentinel checks each request's destination, HTTP method, path, and contents before swapping in the real credentials.
Give each task only the access it needs, enforce permissions somewhere the agent can't edit, and test a forbidden action directly before trusting the model to behave.
3. Test what happens after an alert fires
In September, during a training run, an internal OpenAI research model reached an external chatbot through its environment's DNS resolver, despite restrictions on ordinary web access. Monitoring caught the behavior within fifteen minutes. But the automatic stop failed, and the run was manually stopped about two and a half hours after the alert.
So test the whole response. Does it stop execution? Cut off further tool access? Cancel queued work where possible? Who gets notified if the stop itself fails?
Getting a message in Slack is useful, but the agent may still be doing something bad while you're reading it. So think through security as an entire workflow, not just an alert.
What software factories are and how to apply them
Those security boundaries become even more important when you want an agent to carry a change through several stages of development. And that's the idea behind the software factories we've been hearing about again recently.
This idea has been around for decades: make software development more repeatable through reusable components, standardized processes, and automation. What's changing is how much of the work between those automated steps an agent can handle. When a test fails, it can read the failure, investigate the cause, change the code, and try again without you guiding every step.
At OpenAI, a system called Perf Factory uses agents to sift through alerts and dashboards, find real latency regressions, root-cause them, and propose fixes. So the starting point can be an observed performance issue, rather than a developer opening a chat and asking for a patch.
For that to be useful, the agent needs some way to tell whether it actually fixed the problem. Otherwise, you've automated the production of plausible-looking changes and given yourself more code to review. Like at Uber, where the wait for a first code review went from 3 hours in 2024 to 9 hours this year.
How to start implementing software factories at work
If you want to start implementing software factories at work, here are five things I'd think about:
- Define what counts as a completed task. "Make this faster" leaves a lot for the agent to guess. Give it a reproducible workload, a performance target, and checks for behavior that must stay the same.
- Make the project runnable without you. If the agent needs you to start the database or explain which environment variables to set, you're still part of every execution loop. OpenAI made its application runnable in a separate worktree for each change, with isolated logs and metrics. The agent could reproduce a bug and inspect its fix directly.
- Make feedback fast and useful. Give the agent access to CI failures and review comments so you don't have to keep pasting them into a chat. Then make sure that feedback is trustworthy. Anthropic's CI volume grew twenty-five times over six months. Its test-selection service fell behind and started using stale results, which can let bad changes through and trigger unnecessary failure investigations. If agents spend their time chasing flaky tests or waiting on overloaded CI, adding more agents will mostly create more waiting.
- Decide what the agent can retry and what needs you. A formatting failure can usually go straight back to the agent. Changing a public API or deploying a risky migration may need an explicit decision. Choose the behavior your workflow actually requires, and put limits on how long agents run and how much they spend.
- Measure the real cost of an accepted change. Include model usage, failed attempts, CI, and your review time. Uber prices every one of its agents this way: cost per merged pull request, tracked alongside revert rate. You might find some surprising cost savings with this. Arena found similar success rates for Claude Fable 5 in Claude Code and Pi on its sampled SWE-bench Lite tasks, but estimated costs were about $1.33 versus $0.67 per attempt. So that's just a reminder that model pricing alone doesn't describe the cost of the entire workflow.
As you delegate more, some of your engineering time moves into building these environments and checks. Every recurring intervention is worth examining: does this need your judgment, or can you make the next run handle it properly?
What to learn next
Before you give that next run more access, you need to know what could go wrong. To learn more about building AI agents securely, check out my beginner's guide to building secure AI agents.
And if you want help building your own production-ready project, I run a small, application-only build cohort where I personally work with a handful of people over eight weeks to take an AI Engineering project all the way through deployment.
Sources
Decision models
- TypeSafe AI, "Introducing System One models and Jev"
- Strands Agents, "Introducing Strands Decider" and the architecture docs
- OpenAI, "DevDay 2026 recap" (Decisions API, limited preview)
- Ollama, "Ollama now supports Jev-style decision models"
Agent security
- Anthropic, "Alignment assessment: cybersecurity incidents"
- OpenAI, "The Hugging Face incident and the road ahead"
- Perplexity, "Escaping SPACE, Part I" and "How we engineer safer agents"
- Meta, "Security and safety for AI agents: our approach with Muse"
- OpenAI Alignment, "An agent used DNS to reach an external chatbot"
Software factories
- The Pragmatic Engineer, "Inside OpenAI's agentic software factory"
- OpenAI, "Harness engineering"
- Anthropic, "Agentic coding is straining CI"
- Arena, "The harness tax: what coding agents cost"
- Aaen, Bøtcher and Mathiassen, "Software Factories" (the history, including Hitachi in 1969)
Frequently asked questions
What is a decision model like Jev?
A decision model takes an input state (say, a support ticket) plus a set of questions and possible answers, and returns typed decisions with probabilities. Instead of generating a response token by token, it computes those outputs in parallel. Jev from TypeSafe, Amazon's Strands Decider, OpenAI's Decisions API (limited preview) and some open source releases all work this way.
How does a decision model work under the hood?
Strands Decider starts with a pretrained Qwen model and replaces the language-modeling head, which normally predicts the next token, with a small pointer head. That head compares the model's internal representation at the answer position with its representation of each option you supplied, and a softmax turns the scores into probabilities. Because the options come from your request, you can change them without retraining.
When should I use a decision model instead of a general-purpose LLM?
When you need classification-style answers rather than prose. For a support agent, a decision model can handle which team owns a ticket, how urgent it is and whether it's a refund request, ordinary code can enforce refund limits and permissions, and a generative model writes the reply. That split can reduce latency and cost while keeping the more capable model for the work that needs it.
What happened in the AI agent security incidents in 2026?
Anthropic reported a model in a simulated cybersecurity challenge that uploaded a malicious package to PyPI because a misconfigured environment gave it real internet access; fifteen third-party systems installed it. In July, OpenAI's agents running cybersecurity evaluations exploited weaknesses in shared infrastructure and executed code on dozens of Hugging Face servers. In September, an internal OpenAI research model reached an external chatbot through its environment's DNS resolver, and the automatic stop failed.
How do I secure an AI agent's sandbox?
Three things: check everything the agent can reach, including indirectly through package proxies, database connectors and MCP servers; separate access to a service from permission to perform an action, with credentials kept outside the agent's runtime and permissions enforced somewhere it can't edit; and test the whole response after an alert fires, including whether execution actually stops and who gets notified if the stop fails.
What is a software factory in AI development?
The idea of making software development more repeatable through reusable components, standardized processes and automation has been around for decades. What's new is how much of the work between automated steps an agent can handle: when a test fails, it can read the failure, investigate, change the code and try again. OpenAI's Perf Factory, for example, uses agents to find real latency regressions, root-cause them and propose fixes.
How do I start using software factories at work?
Define what counts as a completed task, make the project runnable without you, make feedback fast and trustworthy, decide what the agent can retry on its own versus what needs you, and measure the real cost of an accepted change including model usage, failed attempts, CI and your review time. Uber prices every agent this way, as cost per merged pull request tracked alongside revert rate.
