Technology Radar
Teams building agents for non-coding work, such as document processing, operations support or migration planning, have typically started with an agent framework and assembled the agent loop themselves. Increasingly, we see teams instead build on a coding harness for general-purpose agents, reusing the runtime of a mature coding agent. Popular coding agents now expose their runtime programmatically through the Claude Agent SDK, the Codex SDK and app-server, OpenCode's server and SDK or Pi's SDK and RPC mode. These harnesses already handle complex aspects of the agent loop, including compacting context on long-running tasks, persisting sessions and running headlessly with the same agent skills, subagents and instructions used in interactive coding-agent sessions. Compared with agent frameworks, the trade-off is less control in exchange for a runtime that's already been tested extensively. We’ve used this approach to build an internal accelerator for .NET application migrations.
However, these harnesses differ in their capabilities. Codex and the Claude Agent SDK provide sandboxing and approval policies, while Pi deliberately leaves guardrails to extensions, making it easier to adapt but requiring more work. Because these runtimes are designed for software development, their system prompts and built-in tools tend to steer agents toward writing and running code. Teams should review these defaults for their intended domain. They should also monitor costs, since coding-agent loops can consume substantial numbers of tokens, and large built-in prompts add to every turn. That's one reason minimal harnesses such as Pi are attractive.
