AI Product Radar — Coding agents and AI development in 2026

Detailed analysis

The source describes the new Codex interface as a “command center” for agents. Each thread is linked to a project and can carry out a separate task; the user switches between threads, reviews changes, comments on the diff and, when necessary, opens the result in their usual editor. Built-in support for worktrees gives each agent an isolated copy of the repository. This reduces conflicts during parallel work and makes it possible to explore several solutions without changing the current local state.

The launch context is important: OpenAI claims that Codex usage doubled after GPT-5.2-Codex, and that more than one million developers used the product during the preceding month. The company attributes this growth not only to the quality of code generation, but also to the expanding scope and duration of tasks: agents work for hours and require a different approach to task assignment, monitoring and acceptance. The application retains configuration and history from the CLI and IDE extension, so the desktop layer serves not as a separate product, but as a shared control panel for local and cloud execution.

The product shift lies in separating the management of work from the direct editing of files. Synchronous “pair programming” remains, but is complemented by asynchronous delegation and parallel execution. OpenAI has also announced Automations with cloud triggers, indicating a move towards agents working continuously in the background.

Limitation of the source: this is a company product announcement, and the stated usage figures are not accompanied by an independent methodology. Worktrees resolve working-copy conflicts, but do not eliminate semantic conflicts, shared architecture issues or the cost of review. Curator inference: the unit around which an AI-native process is designed is no longer the prompt, but the lifecycle of an agent task — assignment, isolation, monitoring, evidence, review and integration.

Why this matters to you

For the independent development of digital products and internal prototypes, this is a “one PM — several parallel implementers” model. It is also useful as a vision of the future enterprise workflow: instead of a shared chat, organisations need task queues, isolated workspaces, change control and explicit acceptance.

What you can apply

• Split tasks into independent workstreams: research, implementation, testing and requirements verification.
• Introduce an agent-task template with acceptance criteria and mandatory evidence.
• Determine which portfolio tasks can genuinely be handled safely in parallel.

Limitations and uncertainty

• Usage metrics were provided by OpenAI itself.
• Parallelism increases the volume of review and the risk of incompatible architectural decisions.
• Windows availability was added after the initial publication.

Sources

1. Introducing the Codex app · primary

Detailed analysis

OpenAI distinguishes between the model and the Codex harness — the shared agent loop and execution logic underpinning the CLI, cloud versions and IDE integrations. On the first turn, the harness constructs a request from system instructions, the user's task, descriptions of the available tools and relevant state. If the model returns tool calls, the environment executes them, stores the results as new conversation items and invokes the model again. The final text appears only when there are no further actions.

The details matter more than the simple outline. Tools must have predictable contracts and return enough information for the next decision without overloading the context. The shell is convenient because of its versatility, but it requires constraints and proper handling of output, errors and lengthy results. History includes not only text but also command results; as it grows, it becomes expensive and degrades the signal. The harness therefore applies compaction: it preserves essential task state while removing less useful details. The engineering risk is losing the very fact that will be needed later.

The piece also explains latency: a single user request may trigger many inference iterations and tool calls. Optimising an individual model response is not the same as optimising the entire task. Caching the recurring prompt prefix, keeping tool outputs compact and completing the loop without unnecessary turns all matter.

The source does not offer a universal recipe and describes OpenAI's implementation. Its strength, however, lies in providing an operational model that can be used to decompose any agent. Curator's inference: teams should evaluate not only the final diff but also the trajectory — what the agent saw, which actions it chose, where it lost context and how many cycles it used.

Why this matters to you

For Epic Validator and BA Tools, this is a direct architectural template: instructions, tools, working memory, verifiable actions and a compaction mechanism. It helps distinguish a model problem from an orchestration problem and identify the cause of a poor result more quickly.

What you can apply

• Log the agent loop trajectory separately from the final response.
• Design concise, typed tool outputs instead of passing entire raw documents.
• Test whether compaction preserves decisions, constraints and open questions.

Limitations and uncertainty

• It describes the specific Codex architecture, not a standard.
• Some implementation details remain in the repository and related pull requests.
• The piece does not experimentally compare alternative harness approaches.

Sources

1. Unrolling the Codex agent loop · primary

Detailed analysis

OpenAI sets out four layers of control. The first is the sandbox: local operations are restricted at the file-system and process levels, while risky transitions require separate authorisation. The second is the network: access to external resources is governed separately because reading untrusted content can lead to prompt injection, while outbound requests can cause data leakage. The third is identity and credentials: the agent must not automatically inherit the user’s entire set of privileges; secrets and credentials should be granted minimally and deliberately. The fourth is centralised rules and managed configs, allowing the organisation to enforce boundaries independently of local preferences.

A separate section covers telemetry. Conventional process logs show what was executed, but do not always connect an action to the agent’s task and decision. An agent-native trail should retain the original request, trajectory, commands, results, approvals and changes. This is necessary for investigations, improving rules and measuring which requests most frequently lead to dangerous actions.

The article’s practical idea is that permissions should be designed around risk, not the number of actions. If the user confirms dozens of harmless commands, their attention is exhausted and control becomes a formality. It is better to define a safe operating perimeter in advance, automatically permit reading and testing within it, and impose strong boundaries on network access, secrets, publishing and changes to external systems.

The source describes OpenAI’s own practices and does not prove the absence of incidents. The curator’s inference: governance for coding agents should be policy-as-code with an observable trajectory, not a checklist for user training.

Why this matters to you

This is a ready-made framework for internal banking and enterprise tools where auditability, separation of privileges and demonstrability matter. It can be used in requirements for an AI platform and when choosing between local and cloud-based agents.

What you can apply

• Create a matrix of actions: automatically permitted, requiring confirmation and prohibited.
• Separate the agent’s identity from the employee’s identity.
• Add the task, tool call, approval, result and modified artefacts to the log.

Limitations and uncertainty

• This is a supplier’s self-report without an external audit.
• Technical boundaries do not eliminate erroneous business decisions within the permitted zone.
• Network allowlists require continuous maintenance.

Sources

1. Running Codex safely at OpenAI · primary

Detailed analysis

The research compares chat with agentic work. Chat typically consists of short, self-contained interactions; an agentic task may run for minutes or hours, use tools, interact with an environment and iteratively correct its output. OpenAI estimates the human equivalent of tasks and demonstrates a shift towards a longer time horizon: by May, 80.6% of individual users had assigned at least one task requiring more than 30 minutes of human labour, and 70.2% had assigned one requiring more than an hour. The share of tasks exceeding eight hours grew fastest, albeit from a low base.

Within OpenAI, engineers were the first to shift most of their AI usage to Codex, but non-technical roles subsequently began to grow faster. Since August 2025, according to the company, the number of weekly non-developer users has increased 137-fold among individual accounts, 189-fold in organisations and 12-fold within OpenAI. People use code as a means of performing analysis, transforming data, automating processes and creating tools, rather than solely as an end product.

The figure of over 60 hours of agent turns per day among users in the 99th percentile reflects parallelism, not a person's physical working time. It demonstrates the user's new function: assembling a portfolio of tasks, monitoring progress and accepting results. However, the research does not establish a causal effect on productivity, quality or employment. The estimate of ‘human hours’ is model-based, the sample of Codex users is skewed towards early adopters, and the data belong to the provider.

Curator's inference: product metrics for an AI tool should account not for the number of messages, but for completed delegated tasks, acceptance quality, rework and the volume of work managed in parallel.

Why this matters to you

For the AI Product Manager role, the piece provides a vocabulary for adoption metrics: not MAU and prompts, but task horizon, the proportion of artefacts successfully accepted, autonomy and the expansion of the range of tasks available to the user.

What you can apply

• Measure completed work and the time taken to achieve an accepted result in products.
• Analyse adoption separately among business analysts, product managers and other non-developer roles.
• Compare claimed time savings with the volume of review and rework.

Limitations and uncertainty

• The data and methodology belong to OpenAI.
• Agent turns do not equal human hours saved.
• The observational research does not prove a causal increase in productivity.

Sources

1. How agents are transforming work · primary

Detailed analysis

The authors introduce a framework for interactive agentic coding: they classify the composition of tasks, the distribution of decisions between the human and Claude, and observable success. The data cover sessions from October 2025 to April 2026. Success is defined not by subjective satisfaction but by verifiable signals — for example, passing tests or committed changes. This is stronger evidence than conventional surveys, although it is not equivalent to validating quality in production.

The main finding is that planning decisions predominantly remain with the human, while execution decisions are delegated to the agent. The greater the user’s relevant expertise, the more useful work Claude performs per instruction. Experts are better at defining the objective, recognising constraints and directing corrections. The success gap between intermediate and expert users is small but consistent. At the same time, people from different professions succeed at coding tasks almost as often as software engineers. The authors’ likely explanation is that a domain specialist can define a substantively correct task, while the agent handles part of the technical execution.

The material does not support the disappearance of the software development profession. The sample consists of people who already use Claude Code; task complexity and quality standards may vary between professions. Automatically observable signals do not reveal the durability of the architecture, its security or its maintainability. Moreover, privacy-preserving classification limits independent reproducibility.

Curator’s inference: in an AI-native team, expertise moves up the chain — towards task definition, decomposition, constraints and evaluation. For BA/PO professionals, this is an opportunity to create working tools directly, but not a reason to skip engineering review in critical systems.

Why this matters to you

The research relates directly to the transition of BA and PM professionals from describing requirements to prototyping and automation. It also suggests what should be taught: not ‘magic prompts’, but planning, domain constraints and verifiable acceptance.

What you can apply

• In the BA Academy, teach task definition, test examples and critical evaluation of the result.
• In analysis, distinguish decisions about the objective from decisions about execution.
• Determine which types of tasks business analysts can complete without a developer’s involvement and which require review.

Limitations and uncertainty

• The sample is limited to Claude Code users.
• Passing tests does not guarantee production quality.
• Privacy-preserving analysis is difficult to reproduce independently.

Sources

1. How Claude Code is used in practice · primary

Detailed analysis

The coding agent works asynchronously: it receives an issue or task, carries out the work in the background, and returns a pull request. The new model picker makes it possible to choose speed or depth for a particular task, or leave routing automatic. This shifts model selection from a global setting to part of the economics of each individual piece of work.

Before opening a PR, the agent now invokes Copilot code review on its own changes, receives feedback, and iteratively improves the patch. GitHub illustrates this by correcting unnecessarily complex concatenation. The more important layer is the inclusion of code scanning, secret scanning, and dependency vulnerability checks during execution. The company emphasises that AI-generated code accelerates not only the creation of value, but also the emergence of vulnerable patterns, secrets, and problematic dependencies. For the coding agent, these checks are provided as part of the workflow.

Custom agents are defined by files in .github/agents/: a team can specify a specialised process, for example measuring performance first, then changing the code and repeating the benchmark. In the demonstration, such an agent reported a 99% improvement in a particular function; this is a specific vendor example, not a general benchmark. Organisation-wide distribution turns instructions into a version-controlled operational practice. Cloud/CLI handoff transfers the branch, logs, and context, reducing the cost of switching between asynchronous and interactive work.

Limitations: self-review by the same system may reproduce its own blind spots; security scanning covers known classes of problems, but not business logic. The curator’s conclusion: a minimum production pipeline for an agent should include independent checks before human review and preserve handoff context.

Why this matters to you

This is an almost ready-made reference workflow for small products: issue → specialised agent → tests and scans → self-review → PR → human acceptance. It also applies to analytical artefacts if code scans are replaced with requirements quality checks.

What you can apply

• Create a custom agent for a requirements validator, with mandatory checks of criteria and examples.
• Add an independent reviewer agent before manual acceptance.
• Route routine tests to a cheaper model and complex refactoring to a more capable one.

Limitations and uncertainty

• Self-review is not an independent guarantee.
• The claimed 99% improvement applies to a single demonstration function.
• Some enterprise capabilities were still being rolled out at the time of publication.

Sources

1. What’s new with GitHub Copilot coding agent · primary

Detailed analysis

GitHub treats the harness as a shared infrastructure component across several Copilot surfaces. This makes it possible to improve the loop once and carry the benefits over to the CLI, app, review and SDK scenarios. Different task classes and models matter in the evaluation: one option may be stronger at fixing a repository, while another may be cheaper or faster for a short task. A single ranking is therefore insufficient.

The methodology separates effectiveness from efficiency. Success measures whether the task was completed according to the verifier or benchmark; token efficiency shows how many resources the harness consumed to achieve the result. This is fundamental for agentic systems: a more capable model may compensate for weak orchestration by using more tokens, while a carefully designed harness may achieve a comparable result at a lower cost. Shared support for many models also requires vendor-neutral tool contracts and the ability to configure behaviour without being tightly coupled to a single provider.

The authors show that harness improvements can alter models’ relative results. Consequently, public model benchmarks do not answer the question of what works best within a particular product. Teams need their own tasks, real repositories, identical constraints and measurement of the end-to-end trajectory. The Pareto frontier is a useful concept: instead of selecting a single winner, choose a set of options for different levels of complexity and budget.

One limitation is that GitHub evaluates its own platform and does not disclose all production data; benchmark success is not the same as maintainability. Curator’s inference: the evaluation set should be a portfolio of typical work, while routing should be a product policy that can be optimised for quality, cost and latency.

Why this matters to you

For AI Product Radar and our own products, this is an argument against choosing the ‘best model’ on the basis of marketing. In practice, it is more important to build a repeatable set of business analyst/product manager tasks and compare complete working configurations.

What you can apply

• Create 20–30 golden tasks from Epic Validator, StaffMap and BA Academy.
• Measure success, tokens, latency, number of interventions and rework.
• Select models using the Pareto frontier for different classes of work.

Limitations and uncertainty

• The study was conducted by the Copilot provider.
• Not all internal data and harness settings are disclosed.
• Benchmark success does not measure long-term maintainability.

Sources

1. Evaluating performance and efficiency of the GitHub Copilot agentic harness · primary

Detailed analysis

In a long session, a substantial portion of the input is repeated: system instructions, repository context, the conversation, tool definitions and the current state. GitHub is increasing the use of prompt caching so that repeated prefixes are not processed as new. The second technique is deferred tools: instead of passing the full tool catalogue on every turn, the harness loads a description when it becomes relevant. This saves tokens and reduces competition between signals in the context.

The third layer is Auto model selection. A quick explanation, a local edit and a complex multi-file task do not require the same model. Routing uses signals from the current work — coding, debugging, planning or tool use — and selects an appropriate configuration. GitHub links this to cost transparency: users should be able to see where premium requests are being spent and which models were used.

The engineering trade-off is that aggressive cost-cutting can impair quality. If the harness defers a necessary tool, removes important history or selects a weak model, the session may spend more turns recovering. The metric should therefore account for the end-to-end cost of a successfully completed task, rather than the price of a single inference. Regression evals on long trajectories are needed.

The material does not disclose the routing algorithm or the absolute savings for specific tasks. This is GitHub’s product narrative, not an independent experiment. Curator inference: context is a managed budget; every block should have an owner, a lifespan and demonstrated utility.

Why this matters to you

For corporate AI tools, costs often rise unnoticed because of large documents and the repeated transmission of rules. This approach helps design the economics of Epic Validator and analytical agents before scaling.

What you can apply

• Classify context as always-on, cached, retrieved or deferred.
• Measure the cost of an accepted result, rather than an individual request.
• Introduce routing based on task complexity and risk.

Limitations and uncertainty

• The Auto-routing algorithm is not disclosed.
• There are no universal savings figures for an external product.
• Deferred context can cause omissions and additional cycles.

Sources

1. Getting more from each token · primary

Detailed analysis

The article begins with the limitations of the prompt-response interface: a production system must do more than offer advice; it must execute a sequence of actions, recover from errors and take state into account. The Copilot SDK takes the execution layer beyond the IDE, enabling developers to use it in their own applications.

Architecturally, the application provides the agent with a restricted set of tools and context, while the harness manages the loop between the model and execution. MCP is used as the standard for connecting external capabilities. This reduces the amount of bespoke orchestration, but shifts responsibility to tool design: parameters must be clear, actions minimal and idempotent, and errors suitable for informing the model’s next decision. The external UI can display the process and results without replicating a conventional chat interface.

The product value becomes apparent in workflows where text is an intermediate result: issue triage, repository analysis, report preparation, system updates or process invocation. However, execution increases risk: an error is no longer merely an incorrect answer, but a change of state. Permissions, previews, audits and human checkpoints are therefore required. The SDK does not relieve the team of responsibility for these decisions.

The material is primarily conceptual and marketing-oriented; it contains no independent comparison of the SDK and does not demonstrate production reliability. Curator inference: a good AI interface should be designed around outcomes, state and controlled actions, with chat retained as one way to initiate and refine requests.

Why this matters to you

BA Tools can evolve from generating recommendations to carrying out controlled operations: creating backlog artefacts, updating templates, running checks and compiling an evidence-based report.

What you can apply

• Design the Epic Validator workflow as a sequence of observable tools.
• Before changing an external system, display a preview and request confirmation.
• Use MCP to decouple business tools from a specific model.

Limitations and uncertainty

• The publication is product-oriented and conceptual in nature.
• The SDK creates a dependency on the GitHub ecosystem.
• Execution increases the consequences of errors and governance requirements.

Sources

1. The era of AI as text is over. Execution is the new interface · primary

Detailed analysis

The VS Code team starts from the premise that agents are taking on more complex and longer-running tasks and therefore need to preserve project context and follow established processes. Hooks connect agent lifecycle events to commands and checks: an organisation can ensure that a formatter, test, security check or other policy is run, rather than hoping that the model remembers the instruction. Skills provide structured knowledge and workflows when they are needed, instead of bloating the persistent prompt.

Browser integration closes an important gap in frontend development: the agent can not only change the code but also open the application, interact with the UI and observe the result. This does not replace visual regression or accessibility testing, but it does add a feedback loop. Mid-response steering allows a person to correct the direction without a complete restart. Memory unifies context across coding agents, the CLI and code review, reducing losses when moving between surfaces.

Long outputs and compaction are a separate problem. The release provides greater control over what may be discarded because automatic compaction can lose an architectural decision or criterion. Taken together, the features demonstrate the IDE's transition from an editor to a control plane: the person manages the agent, policies, memory and evidence.

Limitations: the release material does not measure the impact on the defect rate; more integrations create complexity and new attack surfaces. Curator's inference: reliability is achieved through a combination of soft instructions and strict lifecycle hooks; critical checks cannot be left solely in the prompt.

Why this matters to you

This is a good design for BA Academy and internal platforms: package knowledge as skills, mandatory checks as hooks, and carry user context between stages without manual copying.

What you can apply

• Separate advisory skills from mandatory hooks.
• Add browser-based acceptance testing for user journeys.
• Define which facts must survive compaction and transitions between tools.

Limitations and uncertainty

• There is no data on the features' impact on the quality of production code.
• Shared memory increases privacy and context-cleaning requirements.
• The browser tool does not replace systematic UI testing.

Sources

1. Making agents practical for real-world development · primary

Detailed analysis

The authors distinguish the language model from the agent user experience. The model itself cannot edit a file or run a test: it produces a structured call, which the harness validates and executes. At each iteration, the prompt is reassembled from system rules, context, history and all previous results. A flaw in any part — excessively large context, an unclear tool description, noisy output or incorrect termination — degrades the final result even with a strong model.

Tools define the action space. A set that is too narrow forces the model to work around constraints; one that is too broad makes selection more difficult and increases risk. Context must be relevant and timely: the entire repository cannot be kept in the prompt continuously, so the harness searches, retrieves and summarises. The loop determines when to continue working, request an action or finish. These elements must be tuned jointly for particular models, because different models use identical interfaces differently.

Harness evaluation must be end-to-end. VS Code tests whether the system can complete typical workflows, how many steps and resources it uses, and how it behaves when errors occur. A public model benchmark does not reflect the quality of project search, terminal integration or recovery. When updating the model, the entire stack must undergo regression testing.

One limitation is that the publication describes the product team’s approach without providing the full dataset. Curator inference: the harness should be treated as a distinct product component with versioning, an owner, metrics and its own backlog, rather than as invisible glue code.

Why this matters to you

This model helps explain to leadership why replacing the LLM does not solve quality problems. In Epic Validator, retrieval, validation tools, memory and the completion criterion should be separate targets for improvement.

What you can apply

• Version the model and harness separately in experiments.
• Add trajectory metrics: tool errors, unnecessary loops and context loss.
• Assign an owner to the harness backlog and regression suite.

Limitations and uncertainty

• VS Code’s full evaluation suite has not been published.
• The framework simplifies the models’ complex internal mechanisms.
• The approach does not eliminate vendor-specific tuning.

Sources

1. The Coding Harness Behind GitHub Copilot in VS Code · primary

Detailed analysis

Cursor describes an agent harness through three components: instructions, tools and model. The company configures tools and system instructions for different models because their preferences vary. Rather than trying to guess the internal prompt, the user should focus on providing a high-quality environment and task definition.

Plan Mode is recommended for complex changes. The agent first investigates the codebase, identifies relevant files, asks questions and creates a plan with paths and references. The plan can be edited and saved in .cursor/plans/. If the implementation goes in the wrong direction, it is often cheaper to revert the changes, refine the plan and run it again than to keep correcting the session indefinitely. Small, familiar tasks do not require a formal plan — proportionality matters.

Rules provide always-on context: build commands, style, canonical examples and constraints. Skills are dynamic capabilities activated when relevant. This decomposition reduces noise and makes team practices version-controlled. Specific references to existing code and a defined verification method are valuable: the agent works better when it can run a typecheck, test or benchmark. The team also advises breaking large tasks into smaller pieces and using parallel agents where the branches are independent.

This is guidance from Cursor, the vendor, rather than a controlled study. The advice requires adaptation: a formal plan for every minor task would create overhead, while rules become outdated. The curator’s inference: the best prompt is not a paragraph of eloquence, but a compact specification, access to the right context and an executable verifier.

Why this matters to you

The approach transfers almost directly to business analysis work: an analysis plan, static quality rules, dynamic skills and a verifiable result. It provides a strong foundation for a BA Academy learning module.

What you can apply

• Store plans for significant changes alongside the product documentation.
• Create Rules containing commands, constraints and canonical examples.
• When something fails, improve the plan and verifier rather than merely adding prompts.

Limitations and uncertainty

• The recommendations are based on the Cursor vendor’s own practice.
• Rules and plans require maintenance.
• Excessive planning slows down simple changes.

Sources

1. Best practices for coding with agents · primary

Detailed analysis

The problem begins with a contradiction: auto-approve makes an agent more useful, but an erroneous command could delete data, send a secret or damage the system. Confirming every action appears safe but creates a stream of dialogues that the user stops reading carefully. The effect is amplified when several agents are involved.

Cursor evaluated App Sandbox, containers, VMs and Seatbelt. App Sandbox would require executable binaries to be signed and is poorly suited to an arbitrary toolchain. Containers provide familiar isolation, but on macOS they introduce virtualisation and compatibility problems with the local environment. Full VMs provide stronger isolation but are costly in terms of latency and resources. Seatbelt — macOS’s built-in sandbox-profile mechanism — made it possible to restrict access to paths and the network while running local commands relatively transparently. The specific choice depends on the platform and is not a universal recommendation.

The need to ‘teach’ the agent about the sandbox is particularly interesting. If the model does not know which paths are accessible or what the network rules are, it repeats prohibited commands and consumes context. The harness should provide a clear error and describe a permitted alternative. Security becomes part of the action interface rather than an external blocker.

Limitations: Seatbelt is not portable to Windows/Linux and is not an absolute boundary against operating-system vulnerabilities. The piece was prepared by the vendor. The curator’s conclusion: permissions UX and technical isolation should be designed together; a good restriction helps the agent recover safely.

Why this matters to you

In enterprise AI, this is an argument against endless consent windows. For internal agents, it is better to allocate a restricted workspace in advance and provide clear, auditable escalation points.

What you can apply

• Measure the frequency of confirmations and the proportion of mechanically approved actions.
• Return a structured error to the agent with a safe alternative.
• Separate file, network and credential permissions.

Limitations and uncertainty

• The Seatbelt solution is specific to macOS.
• A sandbox does not protect against logically incorrect actions that are nevertheless permitted.
• The publication includes no independent security audit.

Sources

1. Implementing a secure sandbox for local agents · primary

Detailed analysis

Cursor set out to test whether autonomous development could be scaled by increasing the number of agents. A single agent is constrained by the speed of its sequential loop and the length of its context; the natural next step is to launch many workers. But a shared repository creates dependencies: agents select the same tasks, modify shared components and make incompatible decisions.

The team introduced a planner-workers architecture. The planner analyses the state, formulates tasks and allocates them, while workers implement the changes. Coordination requires continuously updated external state — a single conversational context is insufficient. Tests and other verifiers become a coordination mechanism. The experiment demonstrated the possibility of making real progress on an ambitious project over several weeks, producing more than a million lines of code and consuming trillions of tokens. These figures demonstrate the scale, but do not equate to a million lines of production value.

The main failure modes were duplication, locally correct changes that caused global conflicts, growing technical debt, a planner bottleneck and difficult integration. More agents increase throughput only when there is a modular architecture, a shared plan and rapid verification. Human architectural guidance remains important.

This is a Cursor research experiment; the techniques have yet to influence the product, and full reproducibility is limited. Curator’s inference: multi-agent throughput is a system-level characteristic. Before scaling the number of workers, teams need to invest in breaking down work, ownership, shared state and integration tests.

Why this matters to you

For a portfolio of small products, the conclusion is practical: parallelise independent research and modules, rather than sending several agents into the same poorly structured codebase. It also provides product managers with a model for managing a team of agents.

What you can apply

• Draw a dependency graph of the tasks before launching them in parallel.
• Assign a planner function and maintain a single shared state for decisions.
• Limit concurrency according to the throughput of reviews and tests.

Limitations and uncertainty

• A large volume of code is not a measure of value.
• The experiment was conducted by Cursor itself.
• The cost of trillions of tokens makes the approach impractical for an ordinary team.

Sources

1. Scaling long-running autonomous coding · primary

Detailed analysis

Anthropic claims that Opus 4.6 plans more effectively, sustains agent tasks for longer, works more reliably with large codebases, and performs better at review and debugging. A million-token context window is available for the first time in an Opus-class model, in beta. This makes it possible to include large volumes of code and documentation, but the context-selection problem remains: the availability of a fact does not mean that the model will use it at the right moment.

Claude Code introduces agent teams as a research preview. Multiple agents can work on separate parts of a task, while a lead agent coordinates the results. This accelerates independent branches of work, but retains challenges involving conflicts, cost and integration. The platform now offers effort settings, allowing latency and tokens to be traded for greater reasoning depth. For long-running tasks, this is more useful than a binary model choice: a product can allocate a larger budget only where the risk and complexity justify it.

Anthropic reports leading performance on several evals, including Terminal-Bench 2.0, but these results should be treated as provider claims. A benchmark does not guarantee performance on a particular private repository. A large context window, agent teams and high effort can sharply increase costs, while complex trajectories are harder to verify.

Curator inference: model capability is becoming a resource that the harness must manage. The team should define in advance when agent teams, the million-token context window and high effort are permitted, and link these modes to the task class and verifier.

Why this matters to you

For a product platform, this is an example of policy-based routing: apply an expensive mode to architectural and high-risk tasks rather than making it the default. Agent teams should be tested only on work that can be clearly divided.

What you can apply

• Define task classes and permitted effort/context budgets.
• Compare one strong agent with a team of agents using the same verifier.
• Do not use context-window size as a substitute for retrieval and structured documentation.

Limitations and uncertainty

• Benchmark claims come from Anthropic.
• Agent teams have been released as a research preview.
• Large context windows and parallelism increase costs.

Sources

1. Introducing Claude Opus 4.6 · primary

Detailed analysis

Anthropic positions Opus 4.7 as a direct improvement over 4.6 for difficult, long-running and asynchronous work. The model is expected to follow instructions more carefully and devise its own ways to verify the result. In Claude Code, the separate /ultrareview command launches a specialised session that reads the changes and looks for errors and design issues. This is architecturally useful: creation and critique are separated at least by context and mode, even though they use closely related model families.

Task budgets in the API make it possible to limit or guide reasoning expenditure on long-running work. The new xhigh effort level provides an intermediate choice between high and max; it has become the default in Claude Code. These controls turn reasoning from a hidden model characteristic into a manageable product variable.

The migration notes contain an important economic consideration. The new tokenizer means that identical content may produce approximately 1.0–1.35× as many tokens, depending on its type, while increased effort, particularly in later turns, increases output. A direct model upgrade can therefore alter the budget even without any changes to prompts. Teams need cost regression tests based on real trajectories.

The quality claims and user feedback come from the provider; a separate review does not guarantee independence and may fail to identify a shared blind spot. The curator’s inference: release evaluation should include not only the success rate but also the full cost profile, while critique of the result should be a separate step with its own instructions and criteria.

Why this matters to you

For Epic Validator, a separate reviewer mode is particularly relevant: the generator improves the artefact, while the critic looks for omissions. Task budgets are useful for controlling unit economics and making the choice of an expensive review explainable.

What you can apply

• Separate generator and reviewer prompts and contexts.
• Run cost regression tests on typical tasks before upgrading the model.
• Link high effort to risk, not to the user’s plan.

Limitations and uncertainty

• Review by the same model family is not fully independent.
• Quality is claimed by the provider itself.
• Updated tokenisation increases the unpredictability of costs.

Sources

1. Introducing Claude Opus 4.7 · primary

Detailed analysis

The announcement brings together three product extensions. Plugins adapt Codex to a role and its tools: a package can include instructions, skills and connections so that the agent understands the workflow rather than starting from a generic chat. Sites make it possible to turn an output into an interactive application or workspace page accessible via a URL. Annotations allow users to comment on a specific part of an output and initiate a localised correction, shortening the feedback cycle.

OpenAI gives examples of use beyond engineering: internal applications, dashboards, executive materials and work involving brand constraints. According to the source, Zapier uses context from Slack, Google Docs and Coda for postmortems, incident plans and feature tickets. The company reports more than five million weekly users and says non-developers account for around 20%; these are its own metrics and have not been independently verified.

Architecturally, a plugin is portable operational context. Unlike a long prompt, it can be versioned, distributed and connected to tools. Sites shorten the path from analysis to a working interface, but raise questions about access control, data and maintenance. Annotations make reviews more targeted, which matters for lengthy artefacts.

Curator’s inference: the boundary between ‘creating requirements’ and ‘creating a tool’ is becoming blurred. Business analysts and product managers can independently take discovery through to a working internal prototype, but production ownership, security and lifecycle management do not disappear.

Why this matters to you

This directly aligns with Ekaterina’s portfolio: a role-specific plugin for business analysts and product owners, the publication of educational and analytical mini-applications, and targeted requirements review. It is also a strong career signal for an AI Product Manager.

What you can apply

• Build a plugin containing business analysis methods, templates and tools from lsba.ru.
• Publish secure prototypes for early hypothesis validation.
• Use annotations as a peer-review mechanism for analytical artefacts.

Limitations and uncertainty

• Adoption metrics were provided by OpenAI.
• Rapidly created Sites require governance and ownership beyond the prototype stage.
• Role-specific plugins may entrench an outdated process.

Sources

1. Codex for every role, tool, and workflow · primary

Detailed analysis

AWS links agent speed to the quality of the environment. Even a powerful model loses time if it cannot quickly understand the architecture, run the application, find a contract or verify a local change. Cloud infrastructure may also be too slow and expensive for an iterative cycle. System architecture and codebase structure should therefore be designed together.

At the system level, isolated environments, automated deployment and the ability to create temporary resources quickly are useful. At the code level, this means clear modules, explicit interfaces, tests and documentation located close to the implementation, and consistent build commands. Kiro specifications and design artefacts help teams first capture intent, then translate it into tasks and code. This reduces the risk of an agent implementing a plausible but incorrect assumption.

One compelling idea is feedback latency as a constraint. If a full test takes an hour, the agent either waits or works without a signal. Fast local verifiers and a hierarchy of tests enable more iterations. The same principle improves human work, so agent-readiness often coincides with engineering maturity.

The material sits within the AWS/Kiro ecosystem and naturally steers readers towards these services; universal patterns should be separated from vendor-specific implementation. Curator inference: readiness for coding agents can be assessed as a distinct capability comprising discoverability, setup time, feedback latency, modularity and verifiability.

Why this matters to you

For small independently built products, this is a checklist that can reduce wasted agent time. For an enterprise platform, it can become an assessment of team and repository maturity.

What you can apply

• Measure the time from clone to the first passing test.
• Document canonical commands and module ownership.
• Create an agent-readiness assessment for the repository.

Limitations and uncertainty

• The material is associated with AWS and Kiro.
• Modularity and documentation require investment before delivering visible results.
• Not all legacy systems can be restructured quickly.

Sources

1. Architecting for agentic AI development on AWS · primary

Detailed analysis

The authors observe that ‘harness’ is used to refer to an entire product, an evaluation scaffold, a library or an IDE. They trace its genealogy from a physical harness and test harness to LLM agents, and construct an operational definition. At its core is a layer that connects the model to the environment: it constructs the observation, exposes actions, executes them, returns the result and manages the continuation of the loop.

A harness differs from a framework in its role: a framework helps a developer assemble a system, but does not necessarily manage a specific task trajectory itself. An SDK is a means of programmatic access, a plugin is packaging for a host application, and an orchestrator coordinates multiple workers or tasks. They may contain or use a harness, but are not identical to it. An evaluation harness, in turn, runs and measures an agent on a benchmark, whereas a coding harness performs work for the user.

A rigorous distinction is useful for assigning responsibility. A retrieval error belongs to the context layer, an unsafe action to policy/tool execution, and an infinite loop to termination. Without these terms, everything is attributed to the ‘model’. In procurement, each component and its observability can be examined separately.

This is conceptual rather than experimental work on improving quality; the proposed definition has yet to gain acceptance within the community. Curator inference: the paper’s value lies not in a new technology, but in an architectural vocabulary that makes requirements, incident analysis and vendor comparisons more precise.

Why this matters to you

For Business Analysis, a shared vocabulary is especially valuable: it enables requirements for an agent platform to be decomposed without conflating the model, orchestration, integration and evaluation within a single item.

What you can apply

• Add the terms to the glossary of AI platform requirements.
• Separate ownership of the model, harness, tools, orchestrator and evals.
• Use the boundaries when comparing Codex, Claude Code, Copilot and Cursor.

Limitations and uncertainty

• This is conceptual rather than empirical work.
• The terminology has not yet become an industry standard.
• Component boundaries may overlap in real-world products.

Sources

1. What makes a harness a harness · research

Detailed analysis

The method starts with an editable harness substrate: the agent has a workspace, tools, instructions, skills and middleware that an external meta-level process can modify. Each attempt leaves layered trajectory evidence — not merely success or failure, but also steps, tool calls, errors and intermediate states. The Agent Debugger classifies the cause, after which the evolver proposes a harness change and repeats the evaluation.

The baseline configuration is deliberately simple: a single bash tool, with no skills, middleware or long-term memory. All improvements are measured against the same starting point. The authors claim that observability-driven AHE outperforms human-designed and self-evolve baselines on the selected tasks. The point is not the specific score, but identifying the causes: the model may have had the necessary capability but lacked the right tool, lost context or selected a poor procedure. In that case, changing the harness is cheaper than changing the model.

The danger is benchmark overfitting. The evolver may learn a trick specific to a particular verifier, make the system more complex or weaken its security. Automatically added skills and middleware increase the attack surface and costs. Held-out tasks, change reviews, restrictions on permitted modifications and rollback capabilities are therefore required.

The work is a recent preprint, and its reported advantages require independent reproduction. Curator inference: production logs can be turned into a product discovery loop for the harness, provided that the data is anonymised and every change is tied to a regression evaluation.

Why this matters to you

This is a promising approach for Epic Validator: classify failures, automatically propose improvements to instructions or tools, and accept them only after testing against a golden dataset.

What you can apply

• Create a taxonomy of failure modes from real sessions.
• Link every skill/harness change to a held-out regression suite.
• Retain rollback capability and manual approval for auto-evolved rules.

Limitations and uncertainty

• A recent preprint without broad independent replication.
• A high risk of overfitting to the benchmark.
• Automatic harness modification creates security and governance risks.

Sources

1. Agentic Harness Engineering · research

Detailed analysis

Codex Labs is positioned as a collaborative programme for organisations seeking to move from individual users to systematic adoption. The focus includes selecting workflows, configuring environments and rules, measurement and spreading the practice. Partnerships with global system integrators are intended to provide the capacity to deploy the product across thousands of engineering organisations.

OpenAI provides examples of use across the SDLC. According to the company, Virgin Atlantic is expanding test coverage and increasing team velocity while reducing technical debt and improving performance. Other use cases include legacy migration, code understanding and internal tools. The adoption figures — more than four million weekly developers, up from three million two weeks earlier — indicate rapid growth, but the counting methodology and level of activity have not been disclosed.

The most important conclusion is that the scaling challenge is organisational. It requires repositories with reproducible setups, access rules, champions, training in task specification and review, shared evals and economic metrics. Distributing licences without redesigning the process may increase the volume of code and the review burden without improving lead time.

The piece is an enterprise announcement from OpenAI, so it provides neither causal results nor comparisons with alternatives. Curator inference: an adoption programme should begin with a portfolio of work and a baseline, not the number of seats. Success means accepted changes, quality and reduced cycle time with controlled risk.

Why this matters to you

For those with experience of corporate transformations, this is a familiar situation: technology works only in conjunction with an operating model. The material can be turned into a structure for a coding-agent pilot and criteria for scaling.

What you can apply

• Begin the pilot with 3–5 measurable workflows and a baseline.
• Assess accepted outcomes, cycle time, defects and review load.
• Scale only after governance and the environment have been configured.

Limitations and uncertainty

• The case studies and adoption figures were provided by the vendor.
• There are no control groups or complete economic data.
• The partnership programme may increase vendor lock-in.

Sources

1. Scaling Codex to enterprises worldwide · primary

Detailed analysis

GitHub's evaluation points to an important architectural strategy: Copilot CLI, app and code review use a shared agentic harness. Each surface adds its own UX and context, but the core loop, tools and model integration evolve together. An improvement in token efficiency or tool-call handling can potentially affect several products at once.

This design provides consistency: a single termination policy, a shared telemetry schema and similar methods for recovering from errors. It also simplifies support for more than twenty models. Instead of an ‘each model × each interface’ matrix, the team concentrates adaptation in the shared layer. However, a shared core creates a blast radius: a harness regression can affect the CLI, review and applications simultaneously. Versioning, canary rollouts and surface-specific evals are required.

For an organisation, the pattern means that knowledge, permissions and tools should not be duplicated in every chatbot. It is better to create a shared execution plane and connect the IDE, web, ticketing system and API as clients. At the same time, surface context differs: code review requires a diff and policy, the CLI requires local state, and the application requires business objects. Complete unification is impossible.

The curator's inference is based on the architecture described by GitHub, rather than on a separate product announcement. It should be read alongside the company's efficiency experiments. The main practical idea is that reuse should occur at the level of a controlled agent loop, not merely at that of a shared model endpoint.

Why this matters to you

For the BA Tools ecosystem, a shared agent layer could support Validator, Academy and Assessment while maintaining consistent policies and evals across different user interfaces.

What you can apply

• Design a shared execution core and separate surface adapters.
• Version the harness and run a canary on one channel.
• Maintain a single audit schema across all interfaces.

Limitations and uncertainty

• The conclusion is partly the curator's interpretation.
• A shared core increases the blast radius of a regression.
• Surface-specific context still requires separate evals.

Sources

1. Evaluating performance and efficiency of the GitHub Copilot agentic harness · primary