Faster coding moves the delay to review, testing and release
What the radar says
- Path-to-production mapping moves to Adopt. It is a workshop where everyone involved lists each step from a developer’s laptop to production and marks where work gets stuck.
- Using coding output as a measure of productivity is in Caution. That means numbers such as the share of code written by AI or the number of tokens used. The radar says developers are creating busywork to hit these targets.
- Stacked pull requests, which are chains of small dependent changes, are in Caution. The radar says they often hide poor up-front planning of how to split the work.
- Agent pipeline responsibility is in Assess. Agents should be able to see the build status and follow the same rules as people, such as “do not push when the build is red”.
- In its theme on running more agents, the radar says review capacity and delivery pipelines are the real limits. Teams should check them before adding agent sessions.
What it means for an organization
- More agents do not mean faster delivery on their own. Work waits in review, testing, approvals and release. More agent output makes those queues longer.
- Large, tangled changes are slow to review, no matter who wrote them. How work is split into pieces now affects delivery speed directly.
- Rules that protect the build must be enforced by the pipeline. Agents will not follow rules that exist only in a document.
Critical review
- Strong point. This is the best-supported message in the radar. Its top recommendation here is a workshop, not a product, so it is cheap to act on.
- Weak point. The radar gives no numbers. It does not say how much review capacity is enough or how many agent sessions a team should run. A sensible rule is to add sessions only when the slowest step has spare room, but that is a rule of thumb, not a tested result.
- One-sided. The warning about stacked pull requests is an opinion. Many teams use stacking to keep changes small and easy to review. The radar’s point is fair, but it shows only one side.
- Not covered. How formal approvals, such as change boards and compliance reviews, fit into a faster flow.
Human review works only when people can truly judge what they approve
What the radar says
- Human-in-the-loop theater is in Caution. A person approves things they cannot realistically judge, so nobody truly owns the decision.
- Risk-tiered human oversight is in Trial. People make the riskiest or hardest-to-reverse changes. People review medium-risk changes. The pipeline merges low-risk changes automatically. Teams can mark sensitive areas of the codebase, and can use an AI to rate each change, although the AI can be wrong.
- Meat proxy is in Caution. It means passing on AI output to a colleague without reading or checking it.
- Mutation testing is in Adopt. It adds small deliberate bugs to code and checks that the tests fail. This catches AI-written tests that pass without checking anything.
- Unattended overnight agentic builds are in Trial. An agent works on a feature-sized task overnight and people review the result in the morning. The radar says this needs sandboxes, written specifications and automatic feedback first.
What it means for an organization
- Decide in advance which changes people must make, which people must review, and which can merge automatically. Write this down as policy.
- A review that is only a formality gives you the risk without the control. Cutting review on low-risk changes can make things safer if it leaves people time for the high-risk ones.
- Every person stays responsible for what they pass on, including text and code from an AI.
- Overnight runs are a useful readiness test. If you could not leave an agent working unwatched, you are probably not controlling it well in the daytime either. The radar makes the same point.
Critical review
- The hard part is left to you. The radar does not say how to decide what counts as high risk, and it admits its AI rating is fallible.
- No safe limit is given. There is no evidence yet on how much auto-merging is safe. Start with narrow, easily reversed categories, such as formatting changes, and widen slowly.
- Limited proof. The overnight-build test is clever, but it comes from Thoughtworks’ own teams and has no measured results.
- Not covered. Industries where law or policy requires a named person to sign off on changes.
Machine-checkable designs and specifications help check agent output
What the radar says
- CALM is in Assess. It is an open specification from FINOS for describing software architecture in a standard, machine-readable format. The radar calls it architecture as code. It can be checked against what was built, and teams can manage it in a decentralized way while keeping one overall view.
- TLA+ and Quint are in Assess. Both are formal languages for finding design flaws in distributed systems. The radar says coding agents have made them cheaper to use. It calls the choice between them close: Quint is easier to read and has better tooling, and TLA+ is more mature.
- Tests as data over tests as code is in Assess. Test cases are written as structured data, such as YAML or JSON, and a shared harness runs them. This limits what agents can generate. The same cases can also run against old and new systems during modernization.
- Semantic review of AI-edited prose is in Assess. An AI explains how the meaning of a specification or plan changed, instead of showing a text diff.
- The radar suggests steering systems with mutation testing, property-based testing and formal models, instead of reviewing every change by hand.
What it means for an organization
- When agents write most of the code, checking against a precise statement of what the system must do is worth more than reading code line by line. Key rules, interfaces and behaviors need to be written in a form a machine can check.
- Diagrams and documents drift away from reality, and agents also read them as input. A checkable description helps both people and agents.
- A sensible first step is a pilot on one or two designs where mistakes are costly, such as money movement or workflows with many failure cases.
Critical review
- Nothing here is recommended yet. Every item is in Assess. The CALM entry describes no production use and says nothing about how mature the tools are.
- A new risk the radar skips. An agent-written specification can be wrong in the same way agent-written code can. Someone with the right skills must still review the specification itself.
- Upkeep matters. A machine-readable architecture helps only if it stays current. Otherwise it is one more stale document, which is the problem the radar warns about under documentation sprawl.
- New skills needed. A new format means new training and tools. Check the community and tooling before committing.
Choose the model for each task, and control model traffic in one place
What the radar says
- Blanket frontier model usage is in Caution. It means sending every task to the most capable model without regard to cost or speed. The radar says routine work, such as exploring code, simple edits and summaries, often runs well on smaller or open-weight models.
- Open-weight models are in Trial. These are models whose weights are published, so you can run them yourself. Thoughtworks reports good results from the DeepSeek, GLM and Kimi families on production work and says the gap to proprietary models is much smaller than a year ago. It lists lower cost, less vendor lock-in and better data control as benefits. Self-hosting takes more effort, but major cloud providers now offer managed versions.
- Local coding models moved from Caution to Assess. Small language models are in Trial for narrow, high-volume tasks. Decision models, a new type that returns structured answers such as probabilities instead of text, are in Assess.
- LiteLLM, an AI gateway, is in Trial. Several Thoughtworks teams use it for routing, keys, budgets and guardrails across more than 100 providers. It is held out of Adopt mainly for security reasons: more than 25 reported vulnerabilities (CVEs) this year. agentgateway, in Assess, also covers tool and agent-to-agent traffic.
- Context profiling is in Assess. It means measuring where tokens go before trying to cut them. Naive context compression is in Caution because it can break caching and raise the bill.
What it means for an organization
- Treat model choice as a standing decision with tiers, for example small, mid-range and strongest, and say which kinds of work go where. Do not leave it to each team.
- A gateway gives you one place for keys, budgets, logs and rules. It also becomes a high-value target, because every request and credential passes through it. Run it as critical infrastructure and patch it quickly.
- Switching models is not free. Earlier editions of the radar note that the same prompt behaves differently on different models, and that using provider-specific features brings back the coupling a gateway is meant to remove.
Critical review
- No benchmark figures. “Good results” comes from the radar’s own projects. Test any cheaper model on your own tasks before moving work to it.
- Cheaper per token is not always cheaper per task. The radar itself notes that stronger models sometimes finish with fewer tokens. Measure the cost of a finished task.
- Origin rules. Several of the open-weight models it names (DeepSeek, GLM, Kimi) come from China-based labs, and some organizations restrict that. The radar does not discuss this.
- Missing comparison. The radar does not compare gateways with cloud-provider or API-management products you may already own. Its favored gateway also has a weak security record this year, which is a fair reason to look at alternatives.
Agent instructions, skills and tools need an owner, like any shared software
In this report, the harness means everything around an AI agent: its instructions, skills, tools, memory, guardrails and feedback loops.
What the radar says
- Its theme is that harness engineering is becoming a real discipline, and that a harness is a living asset that needs ongoing ownership.
- Three Caution items show how it goes wrong. Agent instruction bloat: rules pile up and turn long, contradictory and stale. Agent skill cognitive surrender: teams import large skill libraries without understanding them. AI-driven documentation sprawl: generated documents go stale and then mislead the agents that read them. The radar notes that Anthropic removed over 80% of Claude Code’s system prompt for its newest models with no measurable loss.
- In Trial: an agent plugin marketplace (share skills, instructions and tool connections between teams through Git), Agent Package Manager (versions, lock files and provenance for agent assets), a feedback flywheel (ask at the end of each session what shared rules should change), a self-improving harness (agents propose harness changes), and anchoring coding agents to a reference application (agents read current standards from a live example).
- In Assess: an enterprise harness (an organization-wide layer of approved technologies, decision records, security policies and skills), Agent Plugins (an open packaging standard backed by Amazon, Microsoft and OpenAI), and harness quality evaluation (testing that your guardrails and skills work). For the enterprise harness, the advice is to keep it thin and federated, because nobody yet knows how to do this well.
What it means for an organization
- Standards that live only in documents and meetings will not reach agents. They need to live where agents read: templates, reference applications, plugins and automated checks.
- Give the harness an owner, version it, review changes, and delete rules that are no longer needed. After each model upgrade, try removing rules and see what breaks.
- Use open formats so assets can move between agents. Tools change fast, and your assets should outlast them.
Critical review
- Unmeasured. The claim that the harness matters as much as the model is plausible, but nobody has measured it. Most of the Trial items here rest on a few teams.
- The radar pulls in two directions. It wants shared assets across the organization, and it warns about bloat and imported libraries. A central marketplace can make bloat worse unless someone curates it. The radar does not say who should approve what, or how large the shared layer should get.
- Vendor source. The 80% example comes from a vendor describing its own product.
- Early standards. Agent Plugins is described as deliberately minimal and is only in Assess. Avoid heavy investment in one packaging format for now.
- Self-improving harnesses. They sound useful, but the radar itself says gains must be checked, with people setting the limits.
Treat agents as untrusted software, and plan for business users who build
What the radar says
- Agent sandboxing is in Adopt. The radar calls it a sensible default for all agents: run them in isolated environments with limited access, guided by threat modeling.
- Threat modeling is in Adopt. MITRE ATLAS (Assess) is a catalog of attacks on AI systems that helps teams name risks. Toxic flow analysis (Trial) looks for paths where an agent has private data, reads untrusted content and can send data out.
- Stateful guardrails (Trial) check whole conversations instead of single messages. Promptfoo (Trial) tests and red-teams AI applications. It is now owned by OpenAI.
- Supply chain tools: Agent Package Manager scans for hidden characters that could hijack agent behavior. Safe Chain (Assess) blocks very new or known-malicious npm and Python packages. zizmor (Assess) scans GitHub Actions workflows for risky settings. The radar cites an attack this year on the Trivy repository’s workflow.
- Secrets and isolation: Varlock (Assess) keeps real secrets away from agents by giving them placeholders. nono.sh (Assess) isolates agent processes at the operating-system level.
- Data and access: Presidio (Trial) finds and masks personal data before it reaches an LLM. OpenFGA (Trial) handles fine-grained permissions when role-based access is not enough.
- AI-accelerated shadow IT is in Caution. This is people outside engineering building apps with coding agents. The radar’s answer is a safe place to build, for example LibreChat (Trial), where administrators approve which tools are available.
What it means for an organization
- Apply the same controls as for any untrusted code: limited accounts, limited network, no standing credentials, full logs.
- The dangerous combination is private data, untrusted input and a way to send data out. For each agent, remove at least one of the three.
- Skills, plugins and tool servers are part of your software supply chain. Review them before use.
- Business users will build things. A governed place to do it is easier to manage than a ban.
Critical review
- Scattered advice. The guidance is sound but spread over more than a dozen entries. Each organization must assemble it into one set of controls.
- Thin evidence. Many of these tools are in Assess and rest on one team’s experience.
- Known gaps in the tools. The radar itself says Presidio can miss personal data, so do not make it your only control. Promptfoo’s advanced attacks use a hosted service, so check what data leaves your organization. Safe Chain covers only two ecosystems and relies on one vendor’s threat feed.
- Not covered. The radar says little about giving agents their own identities and keeping audit trails of what they did. Both matter for compliance.
Agent runtimes and open standards are forming, but most products are early
What the radar says
- Managed agents runtime is in Trial. Agents run on a platform that handles execution, sandboxing, triggers, credentials, session state and monitoring, instead of on a developer’s laptop. It can be hosted or self-hosted. The radar says to treat it as production infrastructure.
- Examples in Assess: Claude Managed Agents (beta, based on one internal team’s experience, supports only Anthropic’s harness and Claude models, and is not eligible for zero data retention), AWS DevOps Agent (investigates incidents and is billed per agent-second, so costs are hard to predict), and Omnigent (alpha, one set of policies across several coding agents). In Trial: Kagent, which runs agents as Kubernetes resources deployed with GitOps, and Deep Agents, a harness for long-running tasks.
- Coding harness for general-purpose agents is in Trial. Teams build non-coding agents on the runtime of a mature coding agent instead of assembling their own agent loop. The trade-off is less control in exchange for a runtime that is already well tested.
- Open standards: MCP connects agents to tools, A2A connects agents to each other, and Agent Client Protocol (Assess) connects editors to agents. The radar says this makes the agent harness swappable.
- Three command-line coding agents are now in Adopt: Claude Code, OpenAI Codex and OpenCode. Linear (Trial) lets teams assign issues to agents.
What it means for an organization
- Decide where agents run and who operates them, as you would for any workload. They need identity, secrets, logs and cost limits.
- Prefer open standards between agents, tools and editors to limit lock-in.
- Expect to have more than one coding agent. A policy layer above them may help.
Critical review
- Early products. Most claims rest on one team or on beta and alpha products, and the radar says so. Wait for stronger evidence before standardizing on a platform.
- Not a market comparison. The radar says it reflects Thoughtworks’ experience and is not a full market analysis. Its tool picks show what its teams use. Do not read it as a product comparison.
- Cost is a bigger problem than one product. Per-second and per-session pricing make budgets hard to forecast, and the radar offers little beyond gateways to control it.
- Assumes Kubernetes skills. Kagent suits organizations that already know Kubernetes. Others would be adopting a new platform as well as a new tool.
- Ownership changes. Several tools changed owner recently. See the last section.
Few organizations need their own AI infrastructure. Most need cost control.
What the radar says
- Its “AI factory” theme says token costs ultimately come down to infrastructure costs: model choice, routing, batching, data movement and platform efficiency. Kubernetes is becoming the base.
- KServe (Trial) manages model serving on Kubernetes. Thoughtworks teams prefer it for in-house inference platforms, though its newer LLM part is still evolving.
- In Assess: llm-d (distributed inference and scheduling), KAITO (GPU node setup and model deployment, most mature on Azure Kubernetes Service), VAST DataStore (high-speed storage, described as expensive and a vendor tie-in) and Netris (network automation for AI data centers).
- Supporting items: vCluster (virtual clusters for several tenants) and Talos Linux (a locked-down operating system for Kubernetes nodes) are in Trial. VictoriaMetrics, for large-scale metrics, moves to Adopt. VictoriaLogs and Chaos Mesh are in Trial.
- FreeToken (Assess) runs very large open models on consumer hardware.
What it means for an organization
- Most organizations buy AI capacity. Their savings come from the model tiers, routing and budgets covered above, not from running GPUs.
- Running your own inference makes sense only with high volume, strict data rules or tight latency needs. Then you run a fleet that needs a platform team, cost tracking and capacity planning.
- Decide early whether you are a buyer or an operator, so you do not drift into running hardware by accident.
Critical review
- This is for a minority. Most entries are in Assess and come from Thoughtworks teams building AI cloud platforms, which is a specialized setting. Do not generalize from it.
- No cost figures. The radar says infrastructure drives AI cost but shows no numbers. Build a cost model with your own figures before building anything.
- Tie-in and young projects. VAST DataStore is proprietary, KAITO is an early CNCF Sandbox project, and Talos Linux changed owner in 2026.
- Not AI-specific. VictoriaMetrics reaching Adopt is a strong signal, but it is about metrics at very large scale and does not depend on AI.
Clear data and workflow contracts give agents safe boundaries
What the radar says
- Open Data Contract Standard (ODCS) moves to Adopt. It describes a data product’s schema, quality rules and service levels in YAML. It is run by the Linux Foundation’s Bitol project, which graduated in July 2026. The radar says clients building data products are moving to it, and that its format is easier for people and AI agents to read and check.
- Cube Core (Trial) is a semantic layer. Teams define business metrics once, as code, and use the same definitions in dashboards, applications and AI workflows.
- Foundation models for structured data (Assess) are models trained on an organization’s event and transaction data for predictions, with less hand-built feature work.
- Microsoft Copilot Retrieval API (Trial) retrieves text from SharePoint and OneDrive for agents, with access control applied for the calling user.
- Temporal and Restate (both Trial) run long business workflows that survive failures and can wait for a person. Restate now runs a core process in a large insurance system. Kafka share groups (Trial) let many consumers share work from a topic like a queue, without ordering guarantees.
What it means for an organization
- Agents will use your interfaces and data. Contracts, schemas and shared metric definitions work as guardrails because they say what is allowed and expected.
- Long, multi-step agent work looks like a business workflow and needs the same things: retries, saved state and approval steps. Workflow engines such as Temporal and Restate are candidates for this. The radar does not make this link itself. It is my reading.
- When agents fetch company data, keep using the access controls you already have.
Critical review
- Strongest call, with a catch. ODCS in Adopt is the firmest recommendation in this area. But competing standards still exist, and a contract standard works only when teams own and enforce their contracts. A standard does not create ownership.
- Weak link to agents. Temporal, Restate and Kafka share groups are general infrastructure choices. The radar does not present them as agent recommendations.
- Vendor tie-in. The Microsoft retrieval API saves effort and ties you to Microsoft’s ecosystem. The radar does not discuss that.
- Check the fine print. Restate’s server uses a Business Source License that rules out offering it as a managed service. Kafka share groups can deliver a record more than once, and dead-letter queue support is not available yet.
- Little evidence. Foundation models for structured data have few real-world results so far. Watch them, but do not build on them yet.
Measure delivery results, and keep a record of what agents did
What the radar says
- Coding throughput as a measure of productivity is in Caution. The radar recommends DORA metrics (delivery speed and stability) and collaboration quality, tied to business results. It cites Goodhart’s law: a measure that becomes a target stops being a good measure.
- Git AI (Trial) records which lines were written by AI, and by which agent, model and prompt, using git notes.
- Entire CLI (Assess) saves agent sessions, including prompts and transcripts, in the repository so teams can learn from each other. Thoughtworks says some developers disliked sharing every prompt. AgentsView (Assess) lets developers review their own sessions locally instead.
What it means for an organization
- Track outcomes such as lead time, failure rate and recovery time. Do not make AI usage a goal.
- Keep a record of what changed the system and why, for audit, debugging and learning. Choose on purpose whether records are visible to the team or private.
- People stay accountable for work they pass on, with or without an AI.
Critical review
- No new measure offered. The warning about metrics is right, but the radar offers nothing new for measuring agent-assisted work. DORA metrics pre-date agents and do not show review load or rework. Consider also tracking review waiting time and rework rate.
- Records have costs. Recording all prompts has privacy, culture and data-retention costs. The radar notes the pushback from developers. Legal and security teams should also say what may be stored.
- A tension. Git AI counts AI-written lines, which sounds like the metric the radar warns against. Use it for accountability, not for targets.
Self-check and next steps
Decisions to make this quarter
- Run a path-to-production workshop, and set a limit on agent sessions per team based on the slowest step.
- Write the oversight policy: which changes people make, which they review, and which merge automatically.
- Put one gateway in front of model traffic, define two or three model tiers, and set up fast patching.
- Name an owner for shared agent instructions, skills and tools, and schedule a pruning pass.
- Require a sandbox, and the private-data, untrusted-input and outbound-path check, for every agent.
Pilots worth trying
- A machine-checkable architecture description or a formal specification for one or two critical designs.
- ODCS data contracts where data products already exist.
- A managed agent runtime for one low-risk, repeatable workflow.
How far to trust this
- It is experience, not measurement. The radar comes from one consultancy’s project work. It says itself that the benefit of subagents for context management has not been measured systematically. Several entries rest on a single team, such as Claude Managed Agents, the agent suggestion box and Entire CLI.
- Thoughtworks sells AI services. Its own website lists AI/works and Agent/works. Read its recommendations as informed opinion from a company in this market.
- Ownership is changing fast. This year or last, Promptfoo came under OpenAI, Pi under Earendil, LibreChat under ClickHouse and Talos Linux under Yardi. Beads moved to a new maintainer, and Agent Package Manager is sponsored by a major company. Plan for governance and licence changes in open-source tools you depend on.
- The focus is software delivery. The radar says little about AI inside customer-facing products and business processes.
- Tool names date quickly. The radar is a snapshot from a September 2026 meeting. The decisions in this report will last longer than the product names.
- The interpretation is mine. The meanings, critical reviews and priority tags are my reading, not Thoughtworks’ position. This report was prepared with Claude, which is made by Anthropic. Claude Code and Claude Managed Agents are Anthropic products, and I have reported the radar’s views on them as written.
Terms used in this report
- Agent
- An AI system that takes steps on its own, such as editing code, running tests or calling tools.
- Harness
- Everything around an agent: instructions, skills, tools, memory, guardrails and feedback loops.
- Gateway
- One service that sits between your applications and AI models. It handles routing, keys, budgets and logging.
- MCP
- Model Context Protocol, a standard way for agents to connect to tools and data.
- Sandbox
- An isolated environment that limits what a program can read, change or reach.
- Open-weight model
- An AI model whose trained weights are published, so you can run it yourself.
- CVE
- A public identifier for a reported security vulnerability.
- DORA metrics
- Four measures of software delivery: lead time, deployment frequency, change failure rate and recovery time.