Technology strategy
Themes in Technology Radar Vol.35
One team of passionate people experimenting with agents can make almost anything work. They share a context, a credit card and a mental model. They review each other's work because they sit together, and they know what to check and how much latitude to give the coding agent.
Two hundred people, though, cannot work that way. The moment agentic AI becomes an operating model rather than a pilot, a second layer of problems appears: How is context shared between teams? What's the token bill? How do we deal with increased review demands? What's the agent allowed to reach, read and change? And who’s now responsible for the harness everyone depends on?
None of these appear when people are experimenting in isolation and trying things out. They show up when adoption is at scale and sustained over time. They’re AI adoption growing pains, and they’re reflected in the overarching trends in volume 35 of the Thoughtworks Technology Radar.
In this piece, I'll connect the rapid evolution of tools and practices we're seeing on the ground with the macro questions that agentic engineering is raising for organizations that are adopting it.
Scaling human and agent context
How do we share context and expectations between teams?
The first thing that stops scaling isn’t the context window, but shared understanding.
A pilot runs on tacit knowledge. This includes things like which conventions matter, what "done" looks like and which dataset is authoritative. Often none of these things are shared because the people doing the work already know it. That creates a problem when working with agents at scale, though, introducing inconsistency and new forms of friction between teams and across an organization.
A number of blips on this volume of the Radar provide a picture of how this can be achieved in practice. Agent Plugins, in Assess, is an interoperability standard that lets makes it easier to fit independently built things together. Agent Package Manager and agent plugin marketplace, both in Trial, add the distribution layer: publish, pin and compose capabilities instead of copying fragments between repositories. Progressive context disclosure, in Adopt, can also help: the technique is about structuring your context to give the agent the smallest useful slice at the moment it needs it, rather than handing it everything just in case.
Grilling, OpenSpec and interactive visual plans with agents, all in Trial, move the review upstream to the spec. This raises it to the level of intent and makes correction cheaper. Crucially, this lowers the toil burden on human reviewers.
Advice for engineering leaders: Treat context as a shared asset with an owner, not a per-team craft. One definition of done per domain, one evaluation set that encodes it and a review step at the spec rather than only at the diff. If two teams cannot describe the same task the same way, the organization needs to build stronger mechanisms for consistency.
A cheaper model with a good harness will outperform an expensive model with a bad one.
A cheaper model with a good harness will outperform an expensive model with a bad one.
Getting to grips with tokenomics
How do we take control of token spend?
Advanced use of coding agents can chew through tokens much faster than prompt/reply use cases, while a cheaper model used carelessly can cost more than an expensive one that’s used well. This is why effective architectural controls are essential: a cheaper model with a good harness will outperform an expensive model with a bad one.
Routing decides which model sees which request. LiteLLM (Trial) and agentgateway (Assess) sit in the serving path as abstraction and policy layers, the place where cost, latency and residency are enforced. Right-sizing involves deciding whether frontier models are necessary at all: that’s why you see open weight models and small language models in Trial, and GLM and local coding models in Assess.
Placing blanket frontier model usage in Caution isn’t an argument against frontier models, but more an argument against not deciding. A default is never a strategy when there are other options available.
Build or buy?
There’s a bigger strategic question here too. Much of the innovation that makes AI economically sustainable sits deep in the stack, such as serving, storage, network, observability; most organizations should rent more of it than their pride wants to admit. The question that needs to be asked is whether building it is the most valuable thing your engineers could be doing.
Advice for engineering leaders: Manage cost per completed task, not cost per token. Put budgets and routing policy in the gateway, attribute spend to a team and a workflow and review the number alongside quality. Optimizing cost without evaluating where tokens and money is being is not the right approach for making teams effective.
The challenge of human review and cognitive load
How do we absorb the cognitive and review burden?
As humans start to manage more and more coding agents at the same time, it's increasingly burdensome to keep track of them all.
The tooling response is visible across the Tools and Platforms quadrants. Herdr in Assess provides an attention inbox for parallel sessions. Omnigent, also in Assess, offers a meta-harness with persistent worktrees, so sessions stop colliding in one directory. AgentsView and Hunk (Assess) act as review and observability surfaces: the diff, the evidence and the provenance, rather than a scrollback of logs.
Path-to-production mapping deserves particular attention, not least because it's an established practice that has renewed relevance in an agentic era. It emphasizes the importance of following a unit of work and find the bottlenecks; typically such bottlenecks arise as a consequence of the limits of human attention on both definition (specification) and verification.
The Caution ring highlights what happens when none of this is intentionally designed. Human-in-the-loop theater is a blip that warns against dealing with increased review by waving changes through. Meat proxy forwards output without adding review. Coding throughput as a measure of productivity rewards the top of the funnel but hides the queue at the bottom. Agent skill cognitive surrender is a more subtle cost: it captures an antipattern where a reviewer stops forming an opinion because the agent always has one. Stacked pull requests multiply review surfaces; while they're useful in some workflows, they’re not a fix for review load.
Advice for engineering leaders: Fund review as capacity, not overhead. Set a work-in-progress limit per reviewer, rank work by blast radius through risk-tiered human oversight and measure cycle time and rework rather than throughput. The failure mode to watch for isn’t bad code, but unread code that everyone believes was reviewed.
Agent security at scale
How do we secure everything?
Security demands have expanded into the agent supply chain: the packages it installs, the CI it triggers, the secrets it can read and the tools it can call.
For this reason agent sandboxing went straight to Adopt, reflecting how rapidly the industry has moved to delegate work to agents. Varlock, nono.sh and Apple Container in Assess also reflect increasing security needs. Beneath them lie a few important principles: isolate execution, scope credentials and assume the agent will eventually do something unexpected. Each tool you connect is a permission you have granted somewhere else.
The supply-chain hygiene of the last decade applies almost unchanged, which is the good news. However, this volume of the Radar highlights new(ish) tools in this space. Safe Chain blocks brand-new and flagged packages; Zizmor finds injection risks in GitHub Actions. mise in Adopt keeps environments reproducible across humans and agents. The approaches and practices beneath this evolving toolchain aren't particularly novel. It’s really just the same discipline applied to a new class of actor that moves faster than a human and doesn't get tired.
Threat modeling
Threat modeling has to include the agent, not just the application. Threat modeling in Adopt, MITRE ATLAS and Deepsec in Assess and toxic flow analysis for AI and Presidio in Trial give security teams a vocabulary for the questions that matter, such as what data crosses which boundary, which tool calls can be weaponized and where sensitive information can leak.
Advice for engineering leaders: Inventory agent identities and permissions before you inventory models. Default to sandboxed execution, least privilege and age-gated packages; isolate secrets behind a proxy rather than an environment file; and threat-model the agent and its tools.
From platform to harness
How does platform engineering evolve when there’s a new core resource?
The new core resource is the harness. It includes everything from model access, to context assembly, evaluation, sandboxing, identity, spend control and observability. These now need to be delivered as something teams can readily use and depend on.
Most organizations are arriving at this by accident. A team wires up a gateway, another builds an eval, a third invents a sandbox convention. While the result might work, it cannot be audited, priced or upgraded coherently. Enterprise harness is the alternative we think needs to be assessed. Platform teams already own CI, identity and observability; it may make sense for them to own the agent runtime with the same expectations of auditability, access control and lifecycle management.
The harness is effectively the runtime on which agentic work is built; this makes it a platform product. This means it will need things like a roadmap, an SLO and a deprecation policy. Managed agents runtime, in Trial, is the hosted version of the same capability. The supporting cast is familiar from cloud-native platform work: vCluster and Talos Linux for isolation, Temporal and Kafka share groups for durable workflows and queueing, Chaos Mesh for finding out whether any of it survives failure.
Advice for engineering leaders: Name an owner for the harness, publish one golden path and make it faster than the DIY route. Put the runtime in the service catalog with an SLO and a support model. Measure adoption by the share of agent workloads on the paved road, and time-to-first-working-agent for a new team. A platform that's not faster isn't a platform; it's just a policy.
Take your AI adoption growing pains seriously
In our experience, these questions typically arise in the order we presented them:
Shared context is a concern from your second agentic engineering project onward.
Token cost becomes a question as soon as you start doing serious volumes of work with coding agents.
Cognitive load shows up as a problem as you adopt agentic engineering as a system of work.
Security should be a top priority from day one, but it gains a new relevance as the speed and volume of generated code put pressure on your current controls.
Your platform is the challenge that will never be over so long as your organization practices agentic engineering. This is because the platform is how we combine efforts to build things individuals and individual teams cannot.
However, these aren't isolated and discrete issues; they must be answered together. They should be addressed as core foundational elements that emerge as you undergo the strategic shift that agentic software engineering demands. While that’s challenging, tools like the Technology Radar are a useful guide and help you identify what matters, where there are risks and how things may connect.
Most importantly, I urge you to remember that the system we’re trying to build here is primarily a human one. Yes, the technology is sophisticated, but its implementation requires us to properly consider who owns it, who reviews it, who pays for it and who’s accountable when it fails.
