Architecture AI Updates: November 6, 2026

1. Thoughtworks Technology Radar Vol. 35 Maps the Growing Pains of Running Coding Agents at Organizational Scale

Thoughtworks chief architect Chris Ford published the November 2026 macro trends piece on November 4, tying volume 35 of the Thoughtworks Technology Radar (dated November 2026) to five problems that appear when agentic engineering moves from a small pilot to hundreds of people: shared context, token spend, review load, agent security and ownership of the harness. The Radar’s four themes are harness engineering at scale, beyond frontier models, putting more agents to work (developers steering several sessions in parallel, and unattended overnight agentic builds) and constructing the AI factory on Kubernetes with KServe, KAITO, llm-d, LiteLLM, VAST DataStore and Netris. For shared context, Ford points to progressive context disclosure (Adopt), Agent Package Manager and agent plugin marketplaces (Trial) and Agent Plugins (Assess), plus Grilling, OpenSpec and interactive visual plans with agents (Trial) to move review upstream to the spec. On cost, routing layers such as LiteLLM (Trial) and agentgateway (Assess) sit in the serving path, open-weight and small language models are in Trial, GLM and local coding models are in Assess, and blanket frontier model usage is in Caution; he advises managing cost per completed task rather than per token and putting budgets and routing policy in the gateway.

For review load, the Radar lists Herdr, Omnigent, AgentsView and Hunk (all Assess) and places human-in-the-loop theater, meat proxy, coding throughput as a measure of productivity and agent skill cognitive surrender in Caution; Ford recommends a work-in-progress limit per reviewer, risk-tiered human oversight and measuring cycle time and rework instead of throughput. Agent sandboxing went straight to Adopt, alongside threat modeling (Adopt), MITRE ATLAS and Deepsec (Assess) and toxic flow analysis for AI and Presidio (Trial), with advice to inventory agent identities and permissions before models and to isolate secrets behind a proxy rather than an environment file. Enterprise harness (Assess) and managed agents runtime (Trial) frame the harness as a platform product that needs an owner, an SLO, a golden path that is faster than the do-it-yourself route and a deprecation policy. Source Radar

2. Thoughtworks’ Cecilia Geraldo Argues the Agent Harness Needs an Owner, a Versioned Eval Set and a Rollback Path

Thoughtworks lead consultant Cecilia Geraldo argued on November 4, in a companion post to Radar volume 35, that the agent harness should be managed as a product with users, versions, dependencies, a roadmap, quality gates and a named owner. She defines the harness as everything between the model and the work: the instructions and skills the agent loads, the tools it can call, its permissions and sandboxes, the policy that decides what context it sees, the state it carries between steps, the orchestration of its steps, the evaluation of its results and the telemetry for failures. The common failure mode she describes is a prototype that becomes, six months later, a folder of Markdown, a few wrapper scripts, a configuration file with three commented-out experiments and one person who knows why the retry logic exists, which she calls “configuration debt with a system prompt”; packaging through Agent Plugins and Agent Package Manager makes ownership more pressing, because a harness that depends on someone else’s plugin needs compatibility and upgrade management.

Her test strategy replaces activity metrics such as tokens consumed, suggestions accepted and tests passed with a task-based golden set of the 20 to 30 jobs the agent is expected to do, each with a scoring mechanism, versioned alongside the harness and run as a regression on every meaningful change, with cost and latency treated as first-class metrics and sampled human review kept for tone, judgment and style; the rule is “without an eval, there’s no change”. A self-improving harness that rewrites its own instructions, tools or ranking needs three preconditions: an evaluation harness, provenance so every self-authored change can be attributed, reviewed and reverted, and a rollback path, with the system allowed to propose changes but not to approve them. At enterprise scale she lists golden paths, sandbox defaults that do not depend on a developer remembering a flag, plugin allow-lists with provenance checks, a single model routing policy for cost and residency, telemetry that records which harness version produced an output and an explicit answer to whose permissions an agent is using. Source

3. Thoughtworks Guide Separates Context Rot From Context Poisoning and Lists Five Fixes With Their Trade-offs

Piyush Sonawane, writing on the Thoughtworks blog on November 5, described context rot as the decline in a model’s ability to use its working context as that context grows or becomes noisy, citing a 2025 Chroma evaluation of 18 language models in which performance fell as context length increased. He traces it to growing conversation history (ruled-out hypotheses stay in the window), noisy tool outputs (hundreds of lines of test output when a failing assertion and a few stack-trace lines matter), outdated or conflicting information, loading whole repositories upfront and compaction or truncation at window limits, and lists symptoms that appear as a task grows: forgetting earlier constraints, retrying failed approaches, acting on an outdated plan, chasing irrelevant files and making decisions that contradict earlier conclusions. He separates it from context poisoning, where misleading or malicious content enters the context: rot calls for better selection and management of information, poisoning for source validation, and fixing one does not fix the other.

The five fixes each come with a trade-off: filter tool outputs to what the next decision needs (aggressive filtering can drop evidence), summarize long tasks with the goal and constraints, what has been established, which approaches failed and why, the changes made and the open questions (summaries can omit a requirement), retrieve information on demand instead of upfront (retrieval can miss material), keep stable project rules in files such as AGENTS.md or CLAUDE.md apart from temporary task state (persistent instructions go stale), and start a fresh context with a handoff when a task changes or gets tangled (an incomplete handoff loses details). He places these in the agent harness at four points: selecting instructions and retrieving information before a model call, filtering or structuring results after a tool call, updating task state as work progresses, and compacting history or resetting with a handoff when the context becomes unwieldy, together with observability that shows what context the agent received for each decision. Source