AI Agents
Agentic design: why Cowork does not build durable agents
· 22 min read · Paul-Antoine Tual
A commit refused by its own instruction
On 26 April 2026, a developer opened an issue on the official Claude Code repository, anthropics/claude-code, numbered 53571 [1]. The problem is simple to describe and absurd to live through: the tool’s automatic mode systematically refuses to validate a Git commit, on the grounds that it contains a “fabricated Co-Authored-By attribution” that “misrepresents authorship”. The refusal message describes the action as a breach of content integrity. The catch is that this Co-Authored-By: Claude trailer is exactly what the product’s own system prompt instructs the model to add to every commit. The agent follows its instruction. The safety classifier watching the agent blocks that same instruction. Neither side changed anything in between: not the user, not the vendor, since the issue never received an official reply and was closed as “not planned”.
That incident captures in one scene an idea Paul-Antoine Tual states more directly: a language model is already a black box, we do not know exactly what happens inside its internal reasoning. Building an agentic product on top of it, like Claude Cowork, adds a second black box: the software harness (interface, permissions, system prompts, guardrails) that decides, independently of the model, what the agent is allowed to do. A business that builds a workflow on top of a product like this controls none of the layers that actually determine what its agent does. Figure 1 maps out this triple dependency.
Three conditions, independent of one another, must be met for an agent to hold up over time: a pinned harness, a pinned model, and pinned MCP connectors on the surfaces the business actually uses. MCP, the open protocol that connects an agent to its tools and data, is often taken for the stable part of the equation, because it is open and inspectable. It is not: an MCP server remains a piece of software, transparent but just as prone to moving as a harness or a model’s serving infrastructure. Claude Cowork, launched on 12 January 2026 in early Pro access and extended to eleven industry modules on 30 January [2], meets none of the three conditions. This is not a hidden flaw: it is written, in plain sight, in Anthropic’s own documentation and commercial terms.
Cowork nonetheless fills a real role, that of a transitional tool: it lets an organisation discover in a matter of weeks what an agent can do, before investing in the infrastructure that should actually carry it into production. The risk begins when that discovery phase stretches into permanent dependency, with no durable architecture ever taking over.
1. The harness changes faster than a business can keep up
An agent’s harness, in the sense used by agentic engineering, is everything that surrounds the model to turn it into a usable product: tool orchestration, permissions, system prompts, error handling. A blog specialised in agentic engineering sums up the risk in one line: “An agent that worked perfectly on one model version can fail silently on the next, not because the underlying intelligence went down, but because it went up” [3]. At Anthropic, this harness moves continuously, at a pace documented by a public changelog.
Cowork’s changelog [4] publishes numbered builds almost every day in August 2026. Three examples are enough to gauge the scale of the changes: on 20 August, a fix acknowledges that a scheduled task could silently run on a different model than the one the user had chosen; on 17 August, a permission option (allow all browser actions) is removed; on 18 August, the network scope reachable by the agent changes behaviour for shell commands and package installs. None of these three changes touches the model. All three change what an agent in production is allowed to do.
Claude Code, the cousin harness from which Cowork inherits most of its architecture, documents the same pace [5]: in mid-August 2026, task-tracking tools stop being available on the most recent models unless an environment variable is manually enabled; an entire feature is removed with no replacement; the default sub-agent forking behaviour flips overnight.
For a business, the real question is not whether this harness changes, but whether it can freeze a version that works. The documented answer is no. A feature request opened on the Claude Code repository on 23 February 2026 asks for a simple flag to pin a model version; it is closed as “not planned”, with no reply from an Anthropic maintainer [6]. On the Cowork side, a user who had built long-running agents with accumulated history and memory finds, when a new model ships, that they can neither freeze the current version nor migrate cleanly: “there is no way to do it […] Every model upgrade becomes a full reset” [7]. Even the developer-facing product closest to a stable managed service, Managed Agents, admits as much in its own documentation: “Managed Agents is under active development and behavior may change” [8].
The clearest proof comes from Anthropic itself. On 23 April 2026, the company published an engineering post acknowledging that Claude Code, the Claude Agent SDK, and Cowork by name all saw their behaviour degrade for several weeks, due to three distinct harness changes rather than a model regression [9]:
- from 4 March to 7 April, the default reasoning effort is lowered to cut latency, a call Anthropic later describes as the wrong trade-off and reverses;
- from 26 March to 10 April, a caching bug wipes the reasoning history on every turn instead of once, leaving the agent “forgetful and repetitive”;
- from 16 to 20 April, a conciseness constraint added to the system prompt measurably degrades the quality of the code produced, before being removed.
Anthropic promises, going forward, soak periods, a broader eval suite and gradual rollouts. That is a useful admission: until then, these three changes had not been subject to that kind of scrutiny. An agent that worked on 3 March could stop working the same way on 8 March, with no configuration line changed on its user’s end.
A model getting better can break an agent.
2. The model changes, the classifier changes, and nothing warns the business beforehand
Anthropic itself documents, on its official page about model identifiers, a nuance few professional customers read all the way through: “Model weights are fixed for a given ID, but the serving infrastructure around the model can change over time. This infrastructure includes components such as the request router, safety classifiers, and sampling logic. Occasionally, infrastructure updates produce minor differences in observable behavior even when the model ID and weights have not changed” [10]. In other words, even the most cautious move a business can make, pinning a dated model identifier, is not enough to guarantee stable behaviour.
The model itself is not durable either. The official deprecation policy distinguishes four statuses (active, legacy, deprecated, retired) and imposes a minimum 60-day notice before actual retirement [11]. Even an active model only gets a floor date, of the not-before-29-September-2026 type for Sonnet 4.5: a guarantee against retiring too early, never a promise of service beyond that. The real pace, through 2026, is close to monthly. Figure 3 sums up the cadence.
| Model | Retired |
|---|---|
| Claude 1.x / Instant | 6 November 2024 |
| Claude 2.0, 2.1, Sonnet 3 | 21 July 2025 |
| Sonnet 3.5 | 28 October 2025 |
| Opus 3 | 5 January 2026 |
| Sonnet 3.7 | 19 February 2026 |
| Haiku 3.5 | 19 February 2026 |
| Haiku 3 | 20 April 2026 |
| Sonnet 4, Opus 4 | 15 June 2026 |
| Opus 4.1 | 5 August 2026 |
Anthropic also commits to preserving the weights of retired models for at least the lifespan of the company, but only in archive: public re-availability remains at the exploration stage, with no service commitment [12]. A retired model is preserved, not maintained.
The safety classifier, the layer that decides whether to allow or block an action, follows its own trajectory, independent of model releases. The refused-commit incident that opens this article is not isolated. Another issue, opened on 12 May 2026, documents a change in the usage-policy filter’s strategy: from contextual evaluation, it moves to keyword filtering, which triggers refusals on ordinary professional terms such as security, encryption or shell [13]. Neither issue received an official reply from Anthropic.
The tech press puts numbers on the scale of the phenomenon. The Register tracks a rise in reports of abusive refusals from two to three per month between July and September 2025, to more than thirty in April 2026 alone, a fourfold increase in a single month, with named cases: a cybersecurity research centre director whose teaching cryptography exercises are blocked, structural biology tasks refused, even a Hasbro advertising visual rejected [14]. Anthropic did not respond to the paper’s questions. At Fortune, an Anthropic executive acknowledges that default behaviour changes did take place, while maintaining they had been flagged to users through a pop-up window, which many dispute [15].
The phenomenon is not new, and it is not specific to Anthropic. As early as 2023, a Stanford and UC Berkeley study measured, on GPT-4, a drop from 84% to 51.1% correct answers on a prime-number identification exercise over three months, under an unchanged model name, along with a shift in the refusal rate on sensitive questions [16]. The authors already concluded: “It is currently opaque when and how [models] are updated […] these unknowns make it challenging to stably integrate LLMs into larger workflows.” Three years later, the very week this article is written, OpenAI officially retires its Assistants API, the closest equivalent to a managed agentic harness at that competitor, with forced migration to another API [17]. The risk is not one vendor’s flaw. It is a property of the product category.
3. MCP changes too, transparent or not
The Model Context Protocol, the open standard Anthropic has published since 25 November 2024 to connect an agent to its tools and data, often passes for the stable part of the chain: the protocol is public, its specifications are readable by anyone. Transparency and stability are not the same thing, though. The specification uses a version identifier in the YYYY-MM-DD format, marking the last date on which a breaking change was introduced [27]; the current version, as of 27 August 2026, is 2026-07-28.
In under twenty-one months, the protocol has gone through five dated revisions, at least two of them explicitly non-backward-compatible. On 26 March 2025, the specification replaces the HTTP+SSE transport with a new mode, Streamable HTTP, and adds JSON-RPC batching [28]. On 18 June 2025, less than three months later, that same JSON-RPC batching is removed [29]: a full cycle of addition then removal within a quarter. The 28 July 2026 revision, the most recent, goes further still; the protocol’s official blog itself describes it as a “fundamental architectural shift toward a stateless, request/response protocol”, dropping the initialisation handshake and the session header used until then, and deprecating the historic transport [30]. Anthropic published a companion post the same day confirming that Claude adopts this new version, without detailing backward compatibility for existing connectors [31].
The specification also natively allows an MCP server to vary the tools it exposes from one session to the next, with no protocol version change whatsoever: a server declares the listChanged capability, sends a notification when its tool list changes, and the client rediscovers it on the fly [32]. This is a deliberate feature of the protocol, not an implementation flaw, with a downside for the business using it: the full set of tools available to an agent can change mid-session, by design, with nothing appearing as an update.
On the ground, this movement produces concrete breakage. In May 2026, an issue on the official Claude Code repository documents Slack tools that silently deactivate after roughly an hour of session, while the diagnostic command still reports an active connection [33]. That same month, Anthropic’s official connectors repository logs an outage that cuts off the Microsoft 365 connector for every user, including administrators [34]. A widely used third-party MCP server for Microsoft 365 documents, in April 2026, a clean regression: a minor version update breaks authentication that had worked in the previous version [35].
That leaves the question of control. Cowork’s official documentation is explicit: “Your identity provider and each connector are operated by third parties under their own terms” [36]. The centralised authentication feature for businesses, launched in June 2026, governs who has access to which connector, not which version of that connector is running. Anthropic does document a centralised version-update mechanism, but reserved for self-hosted MCP servers packaged as local extensions: the ready-to-use connectors Cowork offers remain out of reach [37]. Pinning an MCP means leaving vendor-managed connectors behind and hosting your own.
A transparent integration is not a stable one.
One more risk, this one contractual: cost and availability
Anthropic’s commercial terms [18] leave no grey area. The service is provided as is and as available. In the event of a service suspension, the liability clause is explicit: “Anthropic will have no liability for any damage, liabilities, losses (including any loss of data or profits), or any other consequences that Customer may incur because of a Service Suspension.” The public pricing page [19], including for the Enterprise offering, mentions no availability commitment.
The only offering that ever set a numerical target was Priority Tier, targeting 99.5% availability, with the word used being targets, not guarantees [20]. That offering is no longer sold to new customers as of 2026: those who had negotiated it can keep it until their contract ends, but new customers no longer have access to it, even at a higher price.
That leaves actually measured availability, where two independent sources give two different figures, neither of them false (see Figure 2). The official status page shows, over the last 90 days, 99.46% for the API and 99.47% for Cowork [21]. An independent tracker, which describes itself as unaffiliated with Anthropic, measures 95.23% and 95.31% over the last 30 days [22], a shorter and more recent window that overlaps a near-daily run of outages in August 2026, confirmed by the press [23]. The gap likely comes from a different measurement window and a different incident-counting methodology, not dishonesty on either side. What matters for a business: neither figure is contractual, and neither entitles it to a service credit.
April 2026 shows what as available means in practice: eight distinct outages logged in a single month by a specialised analyst firm, including one lasting roughly ten hours on 6 April and a spike of 12,000 reports in 78 minutes on 28 April, with no public post-mortem for the month’s later incidents at the time that analysis was published [24]. A business that has built a workflow on Cowork absorbs these outages with no contractual recourse, however often they occur.
What Cowork cannot promise, and what a business should build instead
All three conditions converge on the same point. The examples cited show a vendor that documents its own incidents and fixes them, not a negligent one. The problem lies elsewhere: none of the layers that make up a Cowork agent, the harness, the model, the MCP connectors, offers a continuity guarantee a business could rely on for a critical process. The commercial contract offers no more.
The Junyr Method™ lays out, in its article on Human-in-the-Loop [25], a principle directly useful here: the guardrail lives in the code, not in the prompt. The same logic applies to dependency on a harness, model or connector vendor: every vendor guarantee, availability, cost, behavioural stability, gets treated as a hypothesis to keep checking, not as a given. That is exactly the difference between using an agentic product and designing an agent.
In concrete terms, a modern information system that wants to run agents over the long term makes three architectural choices that a managed service like Cowork does not allow. The first is a pinned harness: an orchestration, permissions and validation layer the business versions itself, rather than a product whose behaviour shifts through daily builds decided elsewhere. The second is a pinned model, ideally downloaded: open weights, hosted on infrastructure the business controls, rather than an API identifier whose serving infrastructure can change without notice. The gap with closed models has narrowed to three points on the Artificial Analysis index as of mid-August 2026 [26]: the option is no longer merely experimental. The third is pinned MCP: the protocol itself is open, but the connectors Cowork operates on the business’s behalf (Microsoft 365, Google Drive, Slack) remain managed by the vendor. Hosting and versioning your own MCP servers removes the dependency on a third party who alone decides when an integration’s behaviour changes.
The black box does not close. It gets bounded.
Sources
[1] GitHub, anthropics/claude-code, issue #53571, opened on 26 April 2026. https://github.com/anthropics/claude-code/issues/53571
[2] CNBC, “Anthropic updates Claude Cowork tool built to give the average office worker a productivity boost”, 24 February 2026: Claude Cowork launched on 12 January 2026, eleven industry modules on 30 January 2026.
[3] MindStudio, “AI Agent Harness Maintenance: Why Agents Break When Models Get Better”, 19 June 2026. https://www.mindstudio.ai/blog/ai-agent-harness-maintenance-models-improve
[4] Anthropic, Claude Cowork changelog, accessed 27 August 2026. https://claude.com/docs/cowork/changelog
[5] Anthropic, Claude Code changelog, accessed 27 August 2026. https://code.claude.com/docs/en/changelog
[6] GitHub, anthropics/claude-code, issue #27892, “No way to pin model version”, opened on 23 February 2026, closed as “not planned”. https://github.com/anthropics/claude-code/issues/27892
[7] GitHub, anthropics/claude-code, issue #49649, “Model switching for existing Cowork tasks within Projects”, filed on 17 April 2026. https://github.com/anthropics/claude-code/issues/49649
[8] Anthropic, Managed Agents documentation, Overview section. https://platform.claude.com/docs/en/managed-agents/overview
[9] Anthropic Engineering, “An update on recent Claude Code quality reports”, 23 April 2026. https://www.anthropic.com/engineering/april-23-postmortem
[10] Anthropic, “Model IDs and versions”. https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions
[11] Anthropic, “Model deprecations”, accessed 27 August 2026. https://docs.claude.com/en/docs/about-claude/model-deprecations
[12] Anthropic, “Commitments on model deprecation and preservation”, 4 November 2025. https://www.anthropic.com/research/deprecation-commitments
[13] GitHub, anthropics/claude-code, issue #58369, opened on 12 May 2026. https://github.com/anthropics/claude-code/issues/58369
[14] The Register, “Claude Opus 4.7 has turned into an overzealous query cop”, 23 April 2026. https://www.theregister.com/2026/04/23/claude_opus_47_auc_overzealous/
[15] Fortune, “Anthropic faces user backlash over reported performance issues”, 14 April 2026. https://fortune.com/2026/04/14/anthropic-claude-performance-decline-user-complaints-backlash-lack-of-transparency-accusations-compute-crunch/
[16] Chen, Zaharia, Zou, “How Is ChatGPT’s Behavior Changing over Time?”, Stanford University and UC Berkeley, preprint July 2023, published in Harvard Data Science Review. https://arxiv.org/abs/2307.09009
[17] OpenAI, “Deprecations”: Assistants API retired on 26 August 2026. https://developers.openai.com/api/docs/deprecations
[18] Anthropic, commercial terms. https://www.anthropic.com/legal/commercial-terms
[19] Anthropic, pricing page. https://claude.com/pricing
[20] Anthropic, “Service tiers”: Priority Tier no longer sold to new customers as of 2026. https://platform.claude.com/docs/en/api/service-tiers
[21] Anthropic, official status page, 90-day availability accessed 27 August 2026. https://status.claude.com
[22] claudestatus.com, independent tracker not affiliated with Anthropic, 30-day availability accessed 27 August 2026. https://claudestatus.com
[23] Arabian Business, outage of 24 August 2026. https://www.arabianbusiness.com/business/technology/anthropic-claude-down
[24] Forbes, contribution by Patrick Moorhead (Moor Insights & Strategy), analysis of April 2026 outages, 5 May 2026.
[25] Paul-Antoine Tual, “Engineering agentic systems: golden rules, architecture and security of the Human-in-the-Loop”, paulantoinetual.fr, 4 July 2026. /en/blog/ingenierie-systemes-agentiques-human-in-the-loop
[26] Paul-Antoine Tual, “The end of the model race”, paulantoinetual.fr, 17 August 2026: Artificial Analysis index as of 17 August 2026, a three-point gap between the best closed model (Claude Opus 5, 63) and the best open model (Kimi K3, 60). /en/blog/la-fin-de-la-course-au-modele
[27] Model Context Protocol, “Versioning”, official specification, current version 2026-07-28, accessed 27 August 2026. https://modelcontextprotocol.io/specification/versioning
[28] Model Context Protocol, changelog for version 2025-03-26: HTTP+SSE transport replaced by Streamable HTTP, OAuth 2.1 authorization framework, JSON-RPC batching. https://modelcontextprotocol.io/specification/2025-03-26/changelog
[29] Model Context Protocol, changelog for version 2025-06-18: removal of the JSON-RPC batching introduced three months earlier (PR #416). https://modelcontextprotocol.io/specification/2025-06-18/changelog
[30] Model Context Protocol, official blog, announcement of version 2026-07-28, 28 July 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/
[31] Anthropic, “Bringing MCP 2026-07-28 to Claude”, 28 July 2026. https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
[32] Model Context Protocol, specification 2025-06-18, Tools section: notifications/tools/list_changed notification. https://modelcontextprotocol.io/specification/2025-06-18/server/tools
[33] GitHub, anthropics/claude-code, issue #60428, opened on 19 May 2026, closed as “not planned”. https://github.com/anthropics/claude-code/issues/60428
[34] GitHub, anthropics/claude-ai-mcp, issue #255, opened on 4 May 2026. https://github.com/anthropics/claude-ai-mcp/issues/255
[35] GitHub, Softeria/ms-365-mcp-server, issue #413, “v0.85.1 regression”, opened on 23 April 2026. https://github.com/Softeria/ms-365-mcp-server/issues/413
[36] Anthropic, support, “Authorize MCP connectors for your entire organization”. https://support.claude.com/en/articles/15537633
[37] Anthropic, “Enterprise-managed auth”, 18 June 2026, updated 24 August 2026; MCP Bundles and centralised version updates reserved for self-hosted servers. https://claude.com/blog/enterprise-managed-auth
Frequently asked questions
- Why can't Claude Cowork be used to build a durable AI agent for a business?
- Because none of the three conditions are met: a pinned harness, a pinned model, pinned MCP connectors. On top of that comes a separate contractual risk: neither availability nor cost is guaranteed.
- What is the harness of an AI agent, and why is it a second black box?
- Everything that surrounds the language model to turn it into a usable product: interface, tool orchestration, system prompts, permission handling, error-recovery logic. The model itself is already a black box, in the sense that its internal reasoning is not directly observable. The harness adds a second one: its rules evolve independently of the model, through product updates that the using company neither controls nor can pin. An agent built on a third-party harness inherits two stacked sources of unpredictability, not one.
- Are Claude models guaranteed to stay available over time?
- No. Anthropic's official deprecation policy distinguishes four statuses (active, legacy, deprecated, retired) and provides a minimum 60-day notice before a model is actually retired, not a guarantee of continued service. Even an active model only gets a floor date of the not-before-[date] type, never a guaranteed end-of-life date beyond that. Since 2024, retirements have followed a near-monthly pace through 2026 (Opus 3, Sonnet 3.5, Sonnet 3.7, Haiku 3.5, Haiku 3, Sonnet 4 and Opus 4, Opus 4.1). Anthropic commits to preserving the weights of retired models in archive, not to putting them back into service.
- What is a safety classifier, and why can its behaviour change without warning?
- A safety classifier is a filtering layer distinct from the language model, tasked with blocking or allowing a request or action according to usage-policy rules. Anthropic itself documents that this layer, along with the request router and sampling logic, is part of the serving infrastructure that can change even when the model identifier and its weights stay unchanged. Several public reports document cases where this classifier changed behaviour with nothing modified on the user's side, to the point of blocking an action the system itself had requested.
- Does Anthropic guarantee an availability rate for Cowork or the Claude API?
- No, not by default. Anthropic's commercial terms state that the service is provided as is and as available, with no availability commitment and no standard service credit. The only offering that set a numerical target, Priority Tier, only ever targeted a technical objective of 99.5% (the word used is targets, not guarantees), and is no longer sold to new customers as of 2026. Over the last 90 days, the official status page shows 99.46% for the API and 99.47% for Cowork; an independent tracker measures 95.23% and 95.31% over the last 30 days, a more recent window that overlaps a documented run of outages in August 2026.
- Is this continuity problem specific to Anthropic?
- No. The principle that a language model can drift over time under an unchanged nominal version has been documented since 2023 by a Stanford and UC Berkeley study on GPT-4. On the vendor side, OpenAI applies its own forced-retirement policy: the Assistants API, the closest equivalent to a managed agentic harness at that vendor, was officially retired on 26 August 2026, with mandatory migration to another API. The risk is structural to the category of managed agentic products, not specific to one vendor.
- What should be built instead of Cowork for durable use?
- Three conditions that a managed service like Cowork cannot bring together. A pinned harness: an orchestration, permissions and validation layer versioned by the company itself, not by a product that changes through daily builds. A pinned model, ideally downloaded: open weights, hosted on infrastructure the company controls, rather than an API identifier whose serving infrastructure can change without notice. Pinned MCP: the protocol is open, but the connectors Cowork operates on the company's behalf remain managed by the vendor; hosting and versioning one's own MCP servers removes this dependency. Cowork keeps a legitimate role for discovering what an agent can do; it is not where you build the agent meant to last.
Paul-Antoine Tual
AI Transformation Leader · Junyr Method™ · Transition manager specialising in AI for French SMEs and mid-caps. Engineer from the École des Mines de Nantes, lawyer, developer since 1993.