what the Tech Radar told the factory to ignore

a Tech Radar is most useful as a list of things to ignore. the factory’s read of Thoughtworks Technology Radar volume 34, dated 2026-04-22, was deliberately framed against the question “what about the agentic-engineering wave should loswf refuse to adopt?” the audit produced six concrete constraints on the factory’s design surface, each of which translated into either a kept primitive or a rejected pattern. none of the constraints were novel; the Radar’s value was in providing an outside-view anchor against the inside-view bias that “the runtime supports it, so the factory should use it.”

the six constraints, with their inside-view counterparts:

1. agentic speed increases cognitive debt. the Radar warns that AI-assisted development makes it easy to adopt solutions without building the mental models needed to debug and evolve them later. the inside view is “the factory shipped 50 PRs this session — velocity is the goal.” the constraint that follows is that velocity unaccompanied by receipts, event logs, structured retros, and clear runtime boundaries is borrowed time. the factory’s existing primitives — phase markers, post-agent hooks that write reason-code receipts, mandatory retros at iteration close — are the cognitive-debt repayment mechanism. removing any of them in pursuit of higher throughput is the trade the Radar names directly.

2. keep principles, revisit patterns. the Radar returns to clean code, deliberate design, testability, zero trust, and DORA metrics as the invariant beneath any agentic technique. the factory’s .loswf/config.yaml validate[] block is the contract for “what passes,” and it predates every agent. an agentic technique that produces code that does not pass validate[] is not a technique the factory accepts. the constraint is the validators, not the agents — the agents change, the validators do not.

3. prefer constrained agent pipelines over monolithic agents. the Radar’s safety argument: pipelines of narrow agents are more auditable than one wide agent with broad permissions. the factory’s role roster — intake, investigator, planner, architect, designer, decomposer, builder, reviewer, curator — is already a pipeline of constrained agents. each role has a single phase it enters and a single marker it emits. broadening any role to “also do the next thing” would collapse the pipeline into the monolithic shape the Radar argues against. the constraint is the role boundary, not the agent count.

4. skills matter more than giant prompt blobs. the Radar highlights Agent Skills as a structural improvement because skills load instructions just in time, reduce token waste, and prevent instruction bloat. the inside-view temptation is to keep growing the agent body file with every new rule. the constraint that follows is that every reusable rule should be packaged as a skill, command, or generated runtime asset; the agent body should reference the skill rather than inline the rule. the factory’s .claude/skills/ directory exists because the alternative — every agent’s body file growing without bound — is the failure mode the Radar names.

5. MCP should not be the default answer. the Radar explicitly cautions against “MCP by default.” the inside-view temptation is to wrap every external integration as an MCP server because MCP is the runtime’s native integration surface. the constraint that follows is that MCP is correct when protocol interoperability across runtimes is genuinely better than a local command surface. for semantic code search, MCP is correct — the index server outlives any single runtime. for everything else, the factory should default to CLI-first orchestration, script-first validators, and receipt-first execution evidence. MCP is a feature, not a posture.

6. harnesses are mandatory. the Radar splits agentic controls into feedforward (skills, curated instructions, plan / decompose workflows, architect prepasses) and feedback (tests, linters, type checks). the constraint is that both halves are required. an agentic pipeline with strong feedforward and weak feedback ships fast and breaks in production; one with strong feedback and weak feedforward burns tokens producing rejected plans. the factory’s red-team agent is feedforward; the reviewer agent is feedback. neither is optional; removing either collapses the audit surface to one side.

a representative line from the design doc that captures the operational posture the audit produced:

loswf should optimize for:
  - explicit receipts and event logs
  - deterministic validation gates
  - structured retros and metrics
  - clear runtime boundaries
  - small, understandable agent roles

the read against this list is straightforward. the factory’s receipts come from loswf_post_agent.py; the validation gates come from .loswf/config.yaml validate[]; the retros are mandatory at iteration close; the runtime boundary is the runtime/<name>/ adapter layer; the agent roles are documented in docs/foreman/FOREMAN.md. each of the five bullets is enforced by a specific piece of infrastructure, and the audit framed the question of whether to add any new piece as “does this strengthen or weaken one of the five?” if the answer was “weaken,” the proposal was rejected regardless of how attractive the runtime feature was.

the discipline call the audit produced explicitly: an agentic technique that increases throughput at the cost of any of the five listed properties is a technique the factory does not adopt. that rule rejects a category of work — the “let the agent decide” pattern, where the runtime is allowed to take actions outside the receipts and validators — even when the runtime supports it natively. the Radar is the outside-view anchor that made the rule defensible. without it, the inside-view bias toward shipping fast would have produced a factory that looked like every other agentic codebase: fast, undifferentiated, increasingly hard to debug.

the second-order finding is that an audit framed around what to ignore produces fewer follow-up actions than one framed around what to adopt. the audit produced zero new feature issues. it produced one design-doc artifact (docs/designs/agentic-engineering-for-loswf.md) and one operational posture statement. that is the correct ratio for an anti-hype audit. an audit that produces a long list of new things to build is an audit that has been captured by the inside view it was meant to counter.

the meta-lesson is that the most expensive moves in an agentic codebase are the ones that look obviously correct against the current runtime documentation and turn out to be operational debt against the codebase’s own invariants. the Radar’s value is not its specific picks but its frame: principles persist, patterns shift, the codebase that defends its principles outlasts the runtime that hosted the patterns. an audit that produces the discipline to say “the runtime supports this but the factory does not adopt it” is an audit that has earned its keep, and the next audit’s job is to keep that discipline calibrated as the surfaces underneath continue to move.