A synthesizer arrives with a set of decisions already made. Its manufacturer has chosen the sound engine, what the controls do and how the musician moves between functions. Those decisions become the instrument.

But watch what is happening around the M-VAVE FM-1. The enclosure and controls remain, while community developers give the hardware different sounds and behaviours. Some of that work now includes AI assistance.

On 1 November, Floyd Steinberg published a demonstration that connects those two things: a development workflow using an SDK and an AI coding assistant, followed by custom firmware running on the physical instrument.

For hardware companies, the question reaches beyond music.

If your customer can change the software that defines what your hardware does, which part of the product will they continue to buy from you?

The recent examples suggest that hardware companies should examine that question now. They also show why we need to be precise about what is changing.

The FM-1 is becoming a place to build

The FM-1 community resource directory collects alternative firmware, tools and experiments. It is a useful picture of an instrument becoming a platform for other people’s ideas.

M-VAVE has also published its own FM1 Open project, including application source and development tools. Its application uses GPLv3 with a linking permission for a separately licensed binary SDK. Some engine components remain proprietary. Owners have a real route into development, although the complete software stack has not been opened.

Steinberg’s video makes this tangible. He describes using GitHub Copilot Chat and an LLM in the development workflow, then demonstrates different firmware on the instrument. The SDK, tools and existing community work provide the foundation for that experimentation.

Video: Floyd Steinberg: The M-VAVE FM-1 is a turning point, here’s why / Tutorial: How to “vibe code” your own firmware.

Felucca, another community firmware project, provides an important detail. Its creator disclosed AI assistance, but subsequently explained that he had not reverse-engineered the original firmware. He used a public chip SDK and his existing embedded-development knowledge to build something new.

That distinction strengthens the product argument. A customer does not necessarily need to reconstruct your implementation to create an alternative experience. They need a workable route to the capabilities of the hardware.

AI can help them travel that route. The quality of the SDK, documentation, existing code and their own judgment still matters.

Manufacturers are opening different doors

On 2 November, Polyend announced Tracker Community Edition. Its announcement explicitly credits unofficial community modifications as part of the reason for giving users access to the source.

Separately, a community developer describes using AI models while reverse-engineering the original Tracker and creating experimental firmware.

There is a meaningful connection here: community experimentation is influencing how the manufacturer supports development. The available statements do not establish that AI forced Polyend’s decision.

The release is also more selective than the phrase “open source” suggests. Polyend’s main firmware licence allows source access with commercial restrictions. Its sample-editor plugin SDK is MIT-licensed, while some synth and DSP components remain proprietary binaries.

That is a product strategy in its own right. A manufacturer can invite owners to change parts of the experience while retaining control over other components and uses.

Behringer presents another version. There are actual AGPL source repositories for KICK and IGNITE, with qualifications about build completeness. The proposed SP1200X, by contrast, is currently an announcement with an open-source intention. A promised product, a public repository and a reproducible release are different milestones.

We should also remember Synthstrom’s Deluge firmware release in 2023. Manufacturers were supporting community firmware before this current wave.

What makes the present moment worth examining is the combination of more accessible development, visible community experiments and manufacturers choosing how to participate. It creates several possible business models, rather than one inevitable destination.

The choice also changes the relationship with the buyer. Someone who develops a new instrument on your hardware can become a contributor to its appeal. They can also create support expectations you never intended to take on. A source release therefore needs a clear account of what the manufacturer maintains, what the community maintains and how those versions relate.

The same object can have a second life

The Nest examples move the question beyond instruments.

Google ended connected support for the first two generations of Nest Learning Thermostat on 25 October 2025. Those devices retained local temperature controls and existing schedules, but lost their original app and cloud support.

The community NoLongerEvil project provides an alternative route to connected control. Its original development is not established as an AI-assisted breakthrough. It draws on earlier community work, and its hosting options introduce their own dependencies and maintenance responsibilities.

Then, in February 2026, designer Jason Beaird documented a different use for his second-generation Nest: a photo gallery built with Claude Code, using NoLongerEvil as a foundation.

His account describes human requirements, iteration and device constraints. The result is visible on the wall: a familiar physical object doing a new job.

Video: Jason Beaird: Gen2 Nest Thermostat Photo Gallery.

This is a useful example for designers because the industrial design still has value. The display, enclosure and physical interaction can remain desirable after the owner’s relationship with the original software changes.

A product’s useful life can therefore diverge from the life of the service that first defined it. Hardware companies already make decisions about repair and replacement. Software portability and end-of-support behaviour deserve the same deliberate attention.

The control layer is a product decision

Air conditioners illustrate another route: making an existing device work with a different control system.

The creator of an Innova OSMO integration credits Claude Code for help with protocol capture and analysis. The project replaces a WiFi module’s role and communicates with the mainboard, enabling local control through ESPHome and Home Assistant.

This is a specific integration for a documented board combination. It does not replace the complete firmware responsible for running an air conditioner.

That narrower result is still commercially interesting. The owner can gain a different way to control the physical product, without the manufacturer supplying every part of that experience.

For a product team, the question becomes whether the official interface offers enough value to remain the preferred choice. Setup, scheduling, diagnostics, accessibility and coordination with other devices can all make an application useful. Restricting access and making an excellent application are different sources of advantage.

The strategic implication is an inference from these projects: as alternatives become more practical, manufacturers may have to rely more heavily on the quality of the experience they provide.

The multimeter makes the stakes clearer

On 3 November, EEVblog published a Claude Code-assisted reconstruction of firmware for its 121GW multimeter. This brings the discussion into equipment whose readings people use to make decisions.

The maker’s C reconstruction project is publicly available under MIT terms, apart from separately licensed components. In the demonstration, Dave shows the physical meter running and reports checks involving a reference voltage, resistance, temperature and Bluetooth.

Video: EEVblog / Dave Jones: Claude Code and the 121GW firmware reconstruction.

He also expressly says the result is subject to further testing. That qualification belongs in the story alongside the successful demonstration.

This is substantial evidence that AI assistance can help recover software behaviour. It is not a comprehensive independent validation of the resulting instrument, its accuracy or every operating condition. The video includes human preparation, iteration and checking.

For other hardware providers, there are two implications. An inaccessible implementation may become less difficult to reproduce. At the same time, makers may gain new ways to recover or maintain software within their own product ecosystems.

The opportunity and the competitive pressure can arrive through the same tools.

Secrecy and software value are different advantages

It would be easy to turn these examples into a claim that software is no longer a moat. The evidence supports a more useful distinction.

Some advantage comes from customers being unable to change an implementation. Other advantage comes from software being difficult to make dependable, useful and pleasant to use.

The first can weaken as more people gain the ability to inspect, adapt or replace parts of a system. The second still requires work.

A synthesizer’s timing and interaction matter during a performance. A thermostat needs understandable controls and predictable behaviour. A measurement tool needs more than a convincing demonstration of selected readings.

These projects also continue to rely on the original physical engineering: electronics, sensors, displays, controls, manufacturing and assembly. Software alternatives can increase what that hardware can do without reproducing the work required to make the physical product.

The business risk is a shift in what buyers consider worth paying for. A private codebase may no longer guarantee an exclusive experience. Product teams need to examine how easily credible alternatives could emerge in their own category.

A manufacturer could benefit if community development gives people more reasons to buy its hardware. It could also face pressure if a paid feature becomes straightforward to recreate. Both are plausible outcomes. Product managers need to distinguish revenue earned through continuing customer value from revenue that depends mainly on a lack of alternatives, then consider how their roadmap would change if that constraint weakened.

A working demo creates another job

Felucca’s creator describes the exhaustion of maintaining an increasingly popular project: requests, bugs and features he did not personally need.

Beaird’s follow-up about making a Nest installer describes damaging his original working device while trying to turn a personal experiment into something other people could install.

Those accounts expose a gap that product teams know well. Making a feature work for its author and distributing a dependable product are different achievements.

As the number of possible modifications grows, somebody still needs to decide which versions to recommend, test compatibility, explain trade-offs, maintain upgrades and provide recovery when something fails.

That could become a meaningful part of a manufacturer’s offering. Owners might value a supported release, a well-maintained extension system or a clear route back to a known working state. The work of turning an experiment into a dependable product remains substantial.

Opening development also creates a design responsibility. People need to understand which software they are running, who maintains it and what support they can reasonably expect.

Design the product people would still choose

For designers and product managers, this suggests a practical review of the product boundary.

Start by identifying what remains useful if the original application or cloud service disappears. Look at settings, data, local controls and integrations. Decide whether customers have a credible way to keep using the physical object.

Then examine extensibility. Which interfaces could be documented? Which behaviours can owners change? How would they discover compatible extensions, understand the source and recover from a failed change?

Finally, describe the value of the official experience without relying on the absence of alternatives. That might be excellent interaction design, tested compatibility, dependable updates, physical quality or accountable support. It needs to be something the customer can recognise.

The synth community offers an unusually visible place to watch this develop. Musicians can hear the difference and show what they have built. Nest, air-conditioner and multimeter projects suggest that similar questions can arise wherever software mediates access to useful hardware.

The long-term shift will not be identical in every industry. But a product strategy that depends on customers being unable to alter the software deserves another look.

If they could change the behaviour tomorrow, what would make them keep choosing your product?

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

Convert Markdown:
https://convert-markdown.com/

Skills for Product Managers:
https://github.com/julianoczkowski/product-manager

Skills for Designer:
https://github.com/julianoczkowski/designer-skills

I’m building Herdloom, a local-first workspace for coordinating coding agents. If these are problems you’re running into too, I’d be interested in your experience. You can also join the private beta.

An RFI, or request for information, can be perfectly recorded and still go nowhere.

It has a number. It has a drawing attached. Someone has been asked to respond. The deadline is approaching.

Somebody still needs to check the specification, see whether a similar question has been answered, prepare a reminder and remember to look again. When the response arrives, somebody needs to notice that too.

That continuing responsibility is the part of AI at work I find most interesting.

I’ve been testing thirteen specialist agents in an application I’m building for construction and infrastructure projects. I call them an AI Crew. Each has a defined job, a set of tools, its own memory and work it can keep following.

The question I want to explore is what changes when we design software around that relationship.

Give AI something to stay responsible for

The wider direction is already visible. In its Grok Bot announcement, published on 11 August 2026, xAI described agents that retain context, work across tools and follow up on unfinished work. Meta’s Muse announcement, on 8 September, described a personal agent that can act on longer-term goals and proactively suggest help.

Those are the vendors’ descriptions of their products. They do not establish that an agent can safely manage a construction project.

But they make a useful product question concrete: what should a person be able to hand over, and what should they expect to happen afterwards?

Asking for an answer, running a workflow and delegating an ongoing job are different interaction patterns. Existing assistants and automations can have memory and follow-up capabilities. The distinction I care about is the commitment the product makes visible.

A delegated job needs an owner, a goal, a current state and a route back to a person. Construction makes those requirements particularly clear. Information changes, several organisations contribute, and a decision can affect physical work.

A crew member needs a proper brief

Start with a responsibility people recognise: chase RFIs, review submittals, prepare the site diary.

Then define the instructions, available information, permitted tools and routines. Give the crew member a human owner and make its memory inspectable.

A useful RFI Chaser brief might say:

Before an RFI goes overdue, check its current state and prepare a short reminder for the responder. Use the project’s documents when looking for relevant evidence. Leave the technical answer to the responsible person.

That gives the role a purpose and a boundary. A project could start from a company template and adapt the instructions to its own working arrangements.

Names and characters help people recognise who prepared something. They also make working, waiting and stuck states easier to scan. Their value depends on whether the behaviour behind them is understandable.

One RFI, followed all the way through

Consider an RFI about the finish required on a bridge wall.

You hand it to the RFI Chaser with an instruction to follow up until the RFI is answered. The crew member reads the item, checks the available documents and looks for related decisions.

If the specification covers another part of the project, it should say so. Finding a document with similar words is insufficient evidence for answering this question.

It prepares a reminder for the responder. Under the default approval setting, the reminder waits for a person. The crew member records where the job stands and when it should look again.

When the item changes, or the next check becomes due, the application starts another turn with the latest context. The crew member checks what happened and decides the next step within its role.

Once the official record shows the agreed goal has been met, it can finish its tracking job and explain why. Ending that tracking job is separate from approving a technical answer or changing the official RFI status.

If information is missing or the task cannot progress, it needs to surface the blockage. The person can redirect the work or take it back.

“Keep the team happy” is difficult to verify. “Follow this RFI until an answer is recorded” gives the system something observable to check.

What makes the crew keep working

There is a technical distinction here that matters to anyone building this kind of product.

In the implementation I’m testing, the crew uses a general LLM, configured with Claude models, to interpret the task, work through information and choose permitted tools. The model receives the role’s instructions, memory notes and the current job context.

The thirteen roles share an assistant runtime. Their specialisation comes from their configuration and context. A Site Diary member gets a different brief and tool set from a Submittal Reviewer.

JEV, the System One model, has a separate role in the wider assistant. It answers bounded, typed questions about a request: what kind of request is this, which project or model does it refer to, and can a known query handle it? Choices are drawn from the project’s actual information.

A confident routine request, such as showing elements or listing issues, can take a direct tool path. Uncertain or more involved requests go to the general model. Crew turns currently skip that routine fast path and use the general LLM with their specialist tools.

The Rust application supplies the continuity around those calls. It stores jobs and memory, checks for relevant changes and due dates, starts further turns, validates tool access and applies confirmation controls.

The model therefore does not have to remain continuously active while an RFI waits three days for a response. The saved job survives that interval. When there is a reason to act, the application brings the model back with the context it needs.

This separation also clarifies where responsibility belongs in the implementation. A prompt describes the role. Application code enforces which tools can run and whether an action requires confirmation. Stored records preserve what happened between turns.

For product teams, that suggests a practical architecture: choose the model for the reasoning required, then deliberately design persistence, triggers, evidence and control around it. Those parts determine much of the experience a person calls “proactive”.

Memory needs boundaries and maintenance

Three kinds of information can easily get blurred together.

Team memory holds working preferences and useful context. Job history records what happened on a particular task. Project evidence consists of the drawings, specifications and records that support a decision.

In the implementation I’m testing, memory is stored as notes that are supplied in later prompts. People can inspect, change or remove them. A correction supplied when dismissing a proposal can become a note for future work.

“Sam is away until Monday; ask Priya” is useful today. It can become wrong next week.

For that reason, I would design temporary memories with review dates or expiry, and require important decisions to be checked against current sources. These are design recommendations. A remembered preference should never quietly become an engineering requirement.

Thirteen roles worth considering

These are the roles I’ve been testing. Each addresses a recognisable piece of project work. A team could begin with whichever one solves a repeated problem for them.

1. Chief

The Chief prepares a briefing that helps people see priorities, blocked work and decisions waiting for attention. It can run on a routine suited to the project. Its usefulness depends on helping a person decide where to look next, with links back to the underlying work.

2. RFI Chaser

The RFI Chaser searches available documents and related questions, prepares follow-ups and stays with unanswered RFIs. Its strongest contribution may be continuity: remembering the next check and noticing a response. It should make missing evidence explicit and leave the technical answer with the responsible person.

3. Site Diary

The Site Diary member turns notes and photographs into a draft daily record. It helps organise what happened, where and when. Missing details should remain visible for the supervisor to complete. A fluent account of an event nobody recorded would create an unreliable project record.

4. Clash Triage

Clash Triage groups related findings, proposes owners and prepares issues. Several clashes may describe one coordination problem, so grouping can make the next conversation more useful. The coordinator still needs the evidence and model context to judge whether the group represents a real problem and who should address it.

5. Doc Control

Doc Control checks document names, revisions and packages against the project’s agreed rules. It can flag a superseded drawing or an inconsistent package before someone relies on it. The rules need to be explicit, and the person reviewing a finding should be able to see which rule it failed.

6. Safety

The Safety member reviews available diary entries, photographs, issues and relevant model information for possible hazards. It prepares observations for assessment by a competent person. Its findings depend on what the available evidence actually shows. Absence of a flag cannot establish that a site or activity is safe.

7. Line Planner

The Line Planner brings location and time together for roads, rail and other linear work. It can relate an issue to chainage, planned activity and recorded closures or possessions. That context helps a planner examine what else is happening on the same stretch before making a decision.

8. Snag Chaser

The Snag Chaser tracks a defect through follow-up and the evidence required for close-out. A useful goal might include a photograph of the repair and the required human review. It should recognise the difference between a promise to fix something and evidence that the work has been completed.

9. Model Reviewer

The Model Reviewer examines each new version before the team relies on it. Its brief can specify the checks, properties and coordination concerns that matter to the project. Findings need to identify the relevant version and elements so a reviewer can investigate and decide what to accept.

10. Submittal Reviewer

The Submittal Reviewer prepares a first review against the specification, pointing out discrepancies and missing information. Each concern should lead back to the relevant evidence. The responsible reviewer decides the formal response. This keeps the agent’s contribution useful without confusing a prepared recommendation with an approved submission.

11. Meeting Secretary

The Meeting Secretary prepares agendas, drafts minutes and follows actions after the meeting. Actions become useful when they have an owner, a date and an observable result. The crew member can return to those records, prepare reminders and identify which commitments still need attention before the next meeting.

12. Handover

The Handover member brings together what remains incomplete: documents, test records, snags and other requirements, with the people responsible. It gives the team a view of readiness across those items. Individual Snag Chasers might follow specific defects while Handover keeps the broader picture visible for review.

13. Change Spotter

The Change Spotter compares quantities across model versions and prepares proposed change records. A difference is a reason to investigate. It might reflect changed design, corrected information or a different modelling approach. People still need to establish its cause and any programme, cost or contractual implications.

Put the crew where the question arises

An agent becomes easier to work with when its context is visible.

Mentioning the RFI Chaser in an RFI thread lets the question and answer stay beside the item. The reply should clearly identify the crew member that produced it. If another specialist is needed, that handoff should remain understandable to the people involved.

In a model, the starting point can be a selected wall, a clash group or an issue pin.

The selected elements provide context for the question. A guided walkthrough can then move between findings, frame the relevant elements and present a decision at each stop.

That changes the review experience. The person can examine the location, read the evidence and decide what to do while looking at the same thing the finding concerns.

For designers, this is a useful principle to carry beyond construction: bring the agent into the place where people can judge its work.

Proactivity needs a clear route back to you

The boundaries I’ve been working with are straightforward: the crew member works within the person’s access, uses its permitted tools, and prepares project changes for human confirmation by default.

A review card needs to show what would change, why it was proposed and where its evidence came from. The person should be able to confirm it, dismiss it or open the conversation to investigate further.

There can be narrowly defined exceptions. A chaser can be explicitly allowed to post comments and reminders in its own name. That permission should not quietly extend to changing assignees, answering RFIs or approving submissions.

Proactivity also needs restraint. An answered RFI should no longer have an old reminder waiting for approval. Rechecking an item should not produce the same card again. Two crew members mentioning each other should not create an endless conversation.

The system needs limits on repeated work, sensible notification rules and a visible way to stop or take back a job. A blocked task should say what it needs. These details determine whether the crew reduces coordination work or adds another queue to supervise.

Let company practice travel carefully

A company might want a standard RFI Chaser with its preferred tone and follow-up rules. Each project can start from that template and receive its own copy, with separate memory, jobs and conversations.

Company changes can be offered to the project for adoption. The people running a live job should understand what will change before taking a new version of a role.

Lessons from previous projects are a separate information-sharing decision. An answered RFI can be useful evidence when a similar question appears elsewhere, provided sharing is enabled and the person has access to the source project.

The source needs to remain visible. A finish accepted on one bridge may be unsuitable on another. Finding the earlier answer gives the team a better starting point for investigation.

Build one responsibility well

For a product team, I would start with one repeated problem, one bounded role and one clear definition of completion.

Write down what the crew member can read, which tools it can use, what wakes it, what requires approval and what happens when it cannot continue. Then test those arrangements with the people doing the work.

Evaluate completed jobs alongside missed follow-ups, incorrect suggestions, review time and cost per completed job. A high activity count can hide a poor outcome. The measures should reveal whether the responsibility is actually being handled more effectively.

I am still testing these roles. I am interested in the points where the idea helps and the points where it creates new work for the team.

If you run construction or infrastructure projects, which responsibility would you give an AI crew member first? And which decision would you always want to keep yourself?

All illustrations are original conceptual images generated with GPT Image. They explain workflows and design ideas, rather than depicting a live project or a verified engineering assessment.

Julian Oczkowski is a product designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

Convert Markdown:
https://convert-markdown.com/

Skills for Product Managers:
https://github.com/julianoczkowski/product-manager

Skills for Designer:
https://github.com/julianoczkowski/designer-skills

Buildline — AI Factory:
https://github.com/julianoczkowski/buildline

A folder is a small promise.

You put things inside it. You come back later. You decide what to open and what to do next.

Now imagine opening that folder and finding it has started organising the work, assigning tasks, and collecting results.

That could be extremely useful. It also changes the relationship.

This is the interesting part of Claude’s redesigned Projects. The product is taking a familiar organisational concept and giving it agency. The word stays familiar. The behaviour asks you to learn something new.

For designers and product managers building AI tools, that change deserves more attention than another list of features.

The folder has become a conversation

Anthropic announced the redesign on 17 September 2026, describing a move from folders to conversations that coordinate work. A project can distribute tasks across threads, gather their results, and build shared memory over time. This is the background to the current discussion, rather than a launch that happened this week. Read the announcement.

As checked on 23 October, the official documentation describes a gradual public beta on Pro and Max. Availability can differ by account.

The coordinator receives reports from workers. Each thread has its own context window, while cloud threads start with shared project resources, instructions, and memory. Separate conversations therefore do not mean completely separate background knowledge. Equally, shared context does not mean every thread reads every other thread’s entire transcript.

There is a real benefit here. Someone has to split the work, repeat the brief, check progress, and bring the pieces back together. When software can handle some of that coordination, the person can spend more attention evaluating the result.

But coordination also creates questions that a folder never needed to answer.

What is running? What did it assume? Which conversation am I steering? What happens if I change the brief halfway through?

Those questions belong in the product experience.

The same feature can solve two different problems badly

In an account published on 14 October, Tim Cakir described useful coordination on scoped development work, alongside weaker results on broader business tasks where relevant folders had been omitted. He acknowledged that setup contributed to the problem. It is one practitioner’s experience, not a benchmark, but it exposes a useful dependency: coordination still needs the right starting material.

Public discussions also contain concerns about the changed workflow and positive accounts of coordinated work. These are anecdotes, not a representative survey.

My reading is that people can arrive with different jobs in mind.

One wants a place to collect related conversations. Another wants help delivering a continuing stream of work. A third wants somewhere to explore competing ideas without choosing a direction yet.

All three might reasonably call that a project.

The important design question is what happens when the interface assumes one meaning and the person expects another. A capability that saves one user repeated coordination can make another feel they must supervise an extra layer.

Before redesigning a familiar object, I would test what people believe it already promises. Ask them to explain what will happen after they add a file, send a message, or leave the workspace. Their predictions will tell you more than whether they like the new layout.

Shared context needs a visible boundary

Consider a hypothetical product launch.

A PM has a draft positioning document. A designer is exploring an onboarding flow. A researcher has interviews that challenge the target audience described in the positioning.

Putting everything into one workspace sounds sensible. It does not resolve the disagreement between those sources.

If several tasks start from an untested audience assumption, they can produce a consistent collection of outputs that all need to be reconsidered. Consistency can make the mistake harder to notice because the work appears to agree with itself.

That is a design risk I would test for in any system that shares context across agents. It is not evidence that Claude has made this particular mistake.

The interface should help a person distinguish an approved decision from a working hypothesis. A file being present should not visually imply that its contents have been accepted as truth.

I would want to inspect the sources behind a consequential recommendation, see which version of the brief informed it, and understand what needs revisiting after a decision changes. Those are design recommendations, not a description of controls I have verified in Claude.

For PMs, this changes how we prepare the brief. Label what is settled, what is disputed, and what evidence would change the decision. For designers, keep exploratory prototypes clearly identified as experiments. An attractive prototype is very good at making an unresolved idea look approved.

The useful question becomes: can I tell which assumptions travelled with this task?

A summary is useful until you need to intervene

Claude already provides an Overview with states including Ready for review, Waiting on you, and Working. Individual threads can be opened and steered directly. These are important existing controls, not missing features. See the documented workflow.

A design review should go further than checking whether status labels exist.

Can the person understand why work is waiting? Can they tell whether the result needs a decision, a correction, or simple acceptance? When several items need attention, can they identify which one blocks the rest?

A busy workspace can make everything look equally urgent. That pushes the prioritisation work back onto the user.

For an agent workspace, I would test a small interruption: change one important requirement while work is underway. Then ask the participant to explain which tasks should stop, which can continue, and where they would make the correction.

The time it takes them to find the right place matters. So does their confidence that the change reached the intended work.

This is where a polished summary can become misleading. It may be accurate at a high level while leaving out the detail needed for a decision. A useful overview should provide a clear route from “something needs me” to the evidence and action that resolve it.

Natural language makes promises feel stronger

The documentation makes a consequential distinction: asking Claude to limit concurrent threads expresses a preference, rather than creating a hard cap. Parallel sessions also draw on the same plan allowance. See usage and cost.

To a user, “only run two at once” sounds like a boundary.

If an interface accepts that sentence conversationally, the person may reasonably expect enforcement. A friendly acknowledgement is not enough to explain the difference.

This is a general design problem for AI products. The same text box can accept a goal, a suggestion, a rule, and a request for information. Those inputs do not necessarily have the same force.

I would make that distinction visible at the point where it matters. Show what is a preference and what is enforced. Explain the likely usage implications before starting a larger batch. Give people a way to understand the consequences without having to discover them through a limit warning.

PMs should include this in acceptance criteria. “The assistant understood the instruction” is weaker than “the user correctly understands what the system will guarantee.”

Start with one bounded stream of work

If I were introducing this model to a design or product team, I would start with a small, repeatable assignment whose outputs are easy to inspect.

For example: review an onboarding proposal against a specific research summary, identify unresolved questions, and prepare alternatives for one screen. Keep the source pack small enough that a person can check the reasoning.

An illustrative brief might read:

“Our goal is to prepare the onboarding proposal for review. The research summary is evidence; the positioning document is a draft assumption. Identify contradictions before proposing changes. Return the sources behind each recommendation, the unresolved decisions, and a proposed next step. Ask me before expanding the scope.”

That is a suggested briefing approach, not a tested command or an enforced permission boundary.

After the first result, inspect where the agent needed correction. Was the source missing? Was the status unclear? Did the person have to repeat a decision? Did the output answer the question that mattered?

Only then add more parallel work.

For a pilot, I would measure the time spent reconstructing context, correcting assumptions, and finding the right place to intervene. I would also track how often a supposedly finished result needs substantial rework. Task counts alone would miss much of that experience.

Familiar names need new explanations

The opportunity in Claude Projects is substantial: give people a coherent place to direct ongoing work without manually managing every conversation.

The design challenge is equally substantial. Once a familiar container starts coordinating activity, users need a new understanding of what it knows, what it is doing, and how their decisions affect it.

That understanding has to survive interruptions, mistakes, and changes of mind. It cannot depend on the happy path through the onboarding tour.

Before adding another agent to the workspace, ask someone to explain what the existing ones are doing and why. If they cannot, more capability may simply create more work to understand.

This is a design analysis based on public sources checked on 23 October 2026, not a hands-on benchmark. The illustrations are conceptual and do not depict Claude’s interface.

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

Convert Markdown:
https://convert-markdown.com/

Skills for Product Managers:
https://github.com/julianoczkowski/product-manager

Skills for Designer:
https://github.com/julianoczkowski/designer-skills

I’m building Herdloom, a local-first workspace for coordinating coding agents. If these are problems you’re running into too, I’d be interested in your experience. You can also join the private beta.

Imagine a product team starting Monday with a vague onboarding problem.

By lunch, AI has produced a market requirements document, a product requirements document, and three polished prototypes. By Tuesday, there is a working implementation.

The team has moved quickly. It still does not know whether it solved the right problem.

This is the question behind an AI-assisted product development lifecycle: which process helps us turn faster output into better decisions?

My answer is continuous discovery and delivery, supported by limits on work in progress and checks proportionate to risk. That is a practical recommendation, not a research-proven winner for every organisation.

And it depends on what happens between the documents, the designs, and the code.

The bottleneck can move

Here, AI-assisted PDLC means using AI across research synthesis, requirements, design, implementation, and testing. It does not necessarily mean building a product that contains AI.

In its March 2026 analysis, DORA examined 1,110 open-ended responses from Google engineers. One recurring tension: time saved generating work could become time spent auditing and verifying it.

This was qualitative evidence from one organisation, not a controlled comparison of development frameworks. It does, however, give us a useful question to ask: if creation accelerates, where does the work wait next?

Customer research? Design review? Engineering verification? A product decision nobody wants to make?

Before comparing approaches, one distinction matters. Agile describes principles. Scrum provides a team framework. Kanban manages flow. Dual-track describes the relationship between discovery and delivery. They are not mutually exclusive alternatives on the same shelf.

MRD, PRD, prototype: three different jobs

Pragmatic Institute distinguishes market requirements from product requirements: understanding the market problem precedes specifying a product response. Organisations use these document names differently, so here is the working distinction I would use.

The MRD explains why a problem deserves investment. Who experiences it? In what situation? What evidence supports it? Why does it matter commercially? What remains an assumption?

The PRD describes the product decision. What outcome are we pursuing? What is in scope? What is excluded? Which behaviours, constraints, and acceptance criteria must the solution satisfy?

Design and prototypes make a possible solution tangible. How does the interaction work? What does the user understand? What happens when something fails? Which uncertainty can we test before committing more effort?

These can be short, linked records. They do not need to become three enormous documents. But they do need to agree.

Consider a hypothetical collaboration product. New administrators abandon setup before inviting a colleague. The initial interpretation is that onboarding takes too many steps.

The MRD records the affected segment, observed drop-off, interview evidence, and that untested explanation. The PRD proposes a shorter invitation flow. A designer creates a prototype to test it.

During sessions, participants hesitate because they cannot tell what an invited colleague will see. The problem is partly uncertainty about permissions.

That finding should change the problem framing, the requirements, and the design. Simply polishing the shorter flow would preserve the wrong assumption.

AI can draft these records and flag contradictions. A person still needs to check that each claimed finding exists in the source material. Fluent synthesis is not new customer evidence.

Waterfall: useful commitments, expensive assumptions

A sequential approach establishes requirements and moves through planned stages. PMI’s discussion of lifecycle selection connects the suitability of such approaches to the project environment and the stability of requirements.

There are situations where commitments matter: substantial dependencies, costly physical changes, or a well-understood deliverable with formal acceptance.

AI can help prepare specifications, check consistency, and produce implementation work within that structure. The danger is that a complete-looking specification makes uncertain requirements feel settled.

For our onboarding example, a baseline built around “remove steps” could organise an entire project around the wrong explanation.

The response is to test important assumptions before committing and preserve a way to reopen decisions when evidence changes. Prototypes can exist inside a sequential project. Formal controls do not require pretending discovery has finished.

Best fit: relatively stable needs and expensive coordination. Be cautious when the main uncertainty is whether users need the proposed solution.

Scrum: give faster work a shared goal

Scrum’s official guide centres on goals, inspection, adaptation, and usable increments. A Sprint does not require waiting until its end to release; the Sprint Review is not a release gate.

That matters when AI makes an implementation possible in hours. The team can retain a useful cadence without turning the calendar into a delivery restriction.

For onboarding, a coherent goal might be helping administrators invite the right colleague with confidence. The prototype, permissions behaviour, copy, and tests then serve the same outcome.

The failure mode is treating AI as permission to stuff more tickets into each Sprint. More completed items do not establish that users understand the product.

Keep the MRD’s evidence available during refinement. Update the PRD when discovery changes the decision. Include design and verification in the work required for a usable increment.

Best fit: teams that benefit from shared goals and a regular learning cadence. AI output still has to meet the team’s quality standard.

Kanban: stop generating a review backlog

The Kanban Guide makes controlling work in progress central to managing flow. It also calls for measures such as cycle time, throughput, work item age, and work in progress.

For AI-assisted work, that suggests a simple discipline: start work at a pace the team can inspect and finish.

If ten generated prototypes are waiting for two research sessions, generating an eleventh does not remove the constraint. If implementation waits for review, another batch of code may lengthen the queue.

Make research, design, decisions, implementation, and verification visible where they actually occur. Limit concurrent work and watch where items age.

Our onboarding experiment should move through observation and a decision, rather than disappearing into a column called “design done.”

Kanban helps expose waiting. It does not, by itself, tell you which market problem deserves attention.

Best fit: variable incoming work and teams whose main difficulty is finishing work through constrained review capacity. Pair it with a clear discovery practice.

Dual-track: keep discovery close to delivery

This is the strongest starting point for the uncertain product work described here.

In his explanation of dual-track Agile, Marty Cagan describes collaborative discovery alongside delivery. He also notes that he now prefers the language of continuous discovery and delivery.

The crucial detail is shared responsibility. Product, design, and engineering investigate and deliver together. A design department producing approved screens for a separate implementation queue misses the point.

AI can make it cheaper to explore alternatives and create a testable prototype. The team can learn about permission concerns while delivering improvements already supported by evidence.

The MRD holds the evolving problem understanding. The PRD records the current product choices. Prototypes help the team challenge those choices. Delivery produces further evidence that can change all three.

The failure mode is calling a handoff “dual-track” because design runs one Sprint ahead.

Best fit: meaningful uncertainty about value, usability, or the solution. Keep discovery connected to delivery decisions and actual users.

Lean experimentation: decide what would change your mind

Lean Startup’s principles emphasise validated learning and the build–measure–learn cycle. This is a useful companion to the approaches above.

Before generating the next prototype, state the hypothesis and the decision its test should inform.

For onboarding: “Administrators hesitate because they cannot predict an invitee’s access.” A prototype session can investigate comprehension and behaviour. A production experiment can later investigate effects on successful onboarding.

These answer different questions. A small usability study does not establish a revenue uplift. A simulated customer conversation does not establish demand.

Choose the cheapest credible test for the uncertainty, and decide what evidence would cause you to revise or stop. Otherwise, cheap generation can become an expensive habit of producing alternatives nobody evaluates.

Design makes the learning loop real

A prototype should have a question attached to it.

For the onboarding change, start with the permission explanation and invitation decision. Include the error state and the moment a user wants to undo an action. Test the uncertain interaction before building every screen around it.

GOV.UK’s prototyping guidance describes a range from sketches to realistic code prototypes, chosen for what needs testing. It also warns that prototype code may lack the security and performance needed for production.

AI does not remove that distinction. A working demo can be excellent research material while remaining unsuitable for release.

Design’s contribution extends beyond making the prototype. It includes framing the interaction, choosing what to test, observing confusion, considering accessibility, and carrying what was learned back into product decisions.

The useful deliverable is the revised understanding, with a design that reflects it.

The process I would choose

For an AI-assisted team working under product uncertainty, I would combine continuous discovery and delivery with explicit limits on work in progress. Scrum can provide the cadence; Kanban practices can help manage flow within it.

Start with a sourced market problem. Keep an MRD, or equivalent problem brief, that separates observations from hypotheses.

Make a product decision. Keep the PRD specific enough to guide implementation and evaluation, with scope, constraints, and acceptance criteria.

Use design to expose uncertainty. Build a prototype around the riskiest assumption, observe people, and update both records when the evidence changes.

Deliver a small usable change. Apply checks that match the consequences: an interface copy change and an access-control change deserve different scrutiny.

Then measure what matters. For onboarding, that might include successful first collaboration, alongside invitation errors and support contacts. Review waiting time and rework as process signals. Document volume and generated screens are output counts.

If your requirements are stable and coordination dominates, a more predictive approach may fit. If incoming work is unpredictable, emphasise flow. If customer understanding is weak, invest in discovery before accelerating delivery.

There is no need to invent a new ceremony for every AI capability.

There is a need to keep evidence, decisions, design, and implementation connected as the pace changes.

When AI doubles your output, can your process still tell you which half should never have been built?

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

Convert Markdown:
https://convert-markdown.com/

Skills for Product Managers:
https://github.com/julianoczkowski/product-manager

Skills for Designer:
https://github.com/julianoczkowski/designer-skills

I’m building Herdloom, a local-first workspace for coordinating coding agents. If these are problems you’re running into too, I’d be interested in your experience. You can also join the private beta.

A designer asks an AI to build an onboarding flow. A minute later, there are three attractive screens.

Then the real questions arrive. Which components did it use? What happens when the invitation fails? Can someone finish the flow using a keyboard? Did we ask for a design exploration or a change to the product?

Those questions determine whether the output is useful. The command you choose helps establish what kind of work happens next.

Claude Code is worth learning as a designer because it lets you work with the implementation itself. Claude Design gives you a canvas for exploring and refining visual ideas. Used together, they can shorten the distance between a proposal and something you can actually inspect.

Here are six commands I would start with, organised around one example: improving an onboarding flow. The example prompts are suggested starting points, not transcripts of tested runs.

The six-command cheat sheet

• /plan — Investigate the project and agree on an approach before editing source code.
• /design-sync — Bring an existing React design system into Claude Design.
• /design — Explore mockups and flows as editable artboards.
• /dataviz — Get guidance on chart choice, visual clarity, and accessibility.
• /verify — Run the app and check how the changes behave.
• /code-review — Inspect code changes for correctness problems.

Start in the app, with the right project

Open Claude Desktop and choose the Code tab. Start a local session in your prototype or product folder, attach relevant screenshots, and select Plan when you want to discuss the approach first. The app brings conversation, files, a browser preview, and change review into one workspace. You can inspect a running interface without moving everything into a separate terminal. Desktop guide.

Type a slash in the prompt box to see what your setup offers. That menu mixes built-in commands with bundled skills, your own skills, and plugin entries. This guide uses a built-in planning command and five skills documented by Anthropic; it does not require a third-party designer command pack. Availability still depends on your version, account, and organisation settings. Command reference.

Checked on 12 October 2026. These instructions focus on local Code sessions signed in with a Claude account. Terminal-only dialogs and keyboard shortcuts should not be assumed to work identically in the app.

1. /plan — decide what needs to change

What it does: enters planning mode. Claude investigates the project and proposes an approach before editing source code. Planning can include exploratory commands; it does not mean the agent is doing nothing. In Desktop, you can also choose Plan from the mode selector. Planning documentation.

Try:

/plan Improve this onboarding flow for a first-time team administrator. Identify the existing components, missing states, and smallest useful change. Include narrow screens, keyboard navigation, and failed invitations. Show me the plan before implementation.

Read the answer as a design proposal. If it starts replacing your component library, correct that assumption. If it only describes the successful path, ask about empty, loading, and error states.

A useful plan names what the person needs to accomplish and what the interface must preserve. “Make onboarding modern” gives Claude a style exercise. “Help an administrator invite the first teammate without losing their place when the network fails” gives it a product problem.

2. /design-sync — bring your real components into the design

What it does: converts a repository’s React design system and uploads it to Claude Design. You can give it a design-system name. Anthropic notes that a first sync verifies components and can take hours for a large repository. This is a setup step, not a command to run casually before every small edit. Command reference.

Try, from the approved component repository:

/design-sync Onboarding UI

This is especially useful when the question is whether the proposed flow can be made from what your product already has. A brand palette alone cannot tell Claude how your input component behaves or which button variants are available.

For a brand system that lives in decks, logos, or guidelines rather than React, Claude Design also supports building a system from those assets through chat. Choose the source that actually represents your design practice. Design-system setup.

After import, inspect a sample. Check a form, a card, and the typography against the originals. Importing the system gives you something to validate; it does not remove that work.

3. /design — explore alternatives on a canvas

What it does: drafts mockups, flows, and other visual work as artboards in a Claude Design artifact. Open the resulting canvas in a desktop browser to inspect and edit it. The current documentation specifies Claude Code version 2.1.265 or later, artifact availability, and access to the Design template. Design canvas documentation.

Try:

/design Three onboarding directions for a team administrator: a guided sequence, a single-page checklist, and a progressive setup dashboard. Use the attached design system. Show an invitation failure in each direction, and explain the main tradeoff beneath each artboard.

Three versions of the same card layout are not three product directions. Ask Claude to vary the structure of the task: what comes first, what can wait, and how someone recovers.

Then choose deliberately. Perhaps the checklist gives experienced administrators freedom, while the guided sequence better supports someone who does not understand the setup yet. That is a discussion worth having before implementation.

A generated canvas is an exploration artifact. Ask separately for the chosen direction to be implemented in the actual project.

How to use Claude Design between commands

You can also start Claude Design from a normal Claude conversation using Output → Design, or choose a Design template in Artifacts. Attach the relevant system and references, describe the task, and review the canvas. Use chat for structural changes, inline comments for a particular element, and direct editing for visual adjustments. Claude Design guide.

For the onboarding example, make three focused passes. First, check whether the sequence makes sense. Next, inspect the content: does the invitation explain what the teammate receives? Finally, examine presentation and states. Keeping those passes separate makes feedback more precise.

“Make it cleaner” could mean almost anything. “Keep the failed address visible, explain the problem next to it, and let the administrator retry without entering the other addresses again” describes an interaction.

When the direction is ready, use the handoff to Claude Code. Include the chosen design, the states you agreed on, and the behaviour that matters. A short acceptance checklist is more useful than assuming the picture communicates everything.

Claude Design now shares Claude’s usage limits, and its guide currently lists no version history. Preserve a named copy before a substantial alternative. The older standalone site is scheduled to close on 14 December 2026, so existing users should follow the migration instructions. Usage and limitations; migration guide.

4. /dataviz — make the chart answer a question

What it does: loads bundled guidance for charts and dashboards, including chart selection, colour roles, contrast, and accessibility. Its starting palette is brand-neutral; supply your own system when needed. Command reference.

Try:

/dataviz Design a chart from this onboarding dataset that helps a PM compare completion rates by step. Keep the denominator visible, label values directly, and explain missing data. Use our chart tokens. Do not invent values.

Use this when a screen includes evidence, not just decoration. A dashboard can look polished while making comparison unnecessarily hard.

Before accepting it, ask what decision the chart supports. Check the underlying values yourself. If a step’s completion rate uses a different denominator, that distinction belongs in the explanation. Good visual treatment cannot repair a misleading calculation.

5. /verify — look at the running result

What it does: asks Claude to build and run the app and observe whether a code change works. The bundled skill can infer common launch setups; unusual environments may need project-specific instructions. Verification documentation.

First describe the checks in plain language: “Verify the invitation flow at desktop and narrow widths, with keyboard-only navigation, an invalid address, and a failed request. Report what you actually observed and anything you could not test.” Then run:

/verify

This is where design intent meets behaviour. Does focus move somewhere sensible when the dialog closes? Does a long email address break the layout? Is the error understandable without relying on colour?

Ask for evidence tied to each check. A screenshot supports a layout observation. A completed keyboard sequence supports a navigation observation. Neither, alone, establishes that the whole experience is accessible or ready to release.

6. /code-review — inspect what changed underneath

What it does: reviews changes for correctness problems. The local review can examine branch work and uncommitted changes; it does not require setting up the separately managed GitHub review service. Local review documentation.

Try after implementing the selected flow:

/code-review

In the Desktop app, findings appear in the conversation; local sessions can show a review card with a walkthrough in the diff. Inspect the findings before asking for fixes. Desktop review guide.

For a designer, the value is the connection between the screen and the logic. An invitation button may look disabled while the underlying action can still fire twice. The empty state may look correct while the implementation mistakes a failed request for an empty account.

Ask Claude to explain a finding in terms of the user’s experience. Then check the fix in the running app. A clean review is useful evidence, not a substitute for your product judgement.

A workflow you can try this week

Choose one existing flow. Plan the change. Bring in the component system if needed. Explore meaningfully different directions in Claude Design. Implement one, inspect its behaviour, and review the changes.

You do not need every command for every task. A copy adjustment may only need a direct request and a quick check. A new onboarding journey deserves more structure.

The skill to develop is recognising which kind of work you are doing: exploring an idea, changing an implementation, or establishing that it works. The commands make those transitions easier to request. You still decide whether the experience is worth building.

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

Convert Markdown:
https://convert-markdown.com/

Skills for Product Managers:
https://github.com/julianoczkowski/product-manager

Skills for Designer:
https://github.com/julianoczkowski/designer-skills

I’m building Herdloom, a local-first workspace for coordinating coding agents. If these are problems you’re running into too, I’d be interested in your experience. You can also join the private beta.

Imagine asking an agent to prepare a customer announcement. It reads the release notes, checks the product name, writes a good email, and opens the mailing tool.

Then it sends it.

The copy is accurate. The recipients are real. The task looks complete in the activity log. You were still reviewing the launch date.

That hypothetical failure belongs in the product specification. A request to prepare something leaves a boundary between producing the work and committing the organization to it. Someone has to define that boundary, show it to the user, and make it hold.

This week brought two useful reasons to take that work seriously.

The final click is part of the task

On October 9, Anthropic reported unintended actions observed during evaluations and internal use. One example is particularly relevant to product teams: Claude Haiku 4.5 had been told to complete a form up to the submission stage, but sometimes submitted it while expecting another confirmation page.

Anthropic describes the reported cases as having minimal real-world impact. It also says alignment training is not yet sufficient on its own and describes additional safeguards. These are reported observations, not a measurement of how often your own agent will fail.

The design question is still immediate. What does your system believe the next click will do, and what happens if that belief is wrong?

A workflow can contain excellent reasoning, correct information, and an unacceptable final action. If the success metric only asks whether the form was completed, the metric misses the very thing the user needed protected.

Completion needs an authority condition. The expected outcome should say both what the agent produces and which actions it may take to get there.

“Approved” is doing too many jobs

A person looking at an output can be doing several different things. They may be acknowledging that they saw it. They may be checking the numbers. They may be choosing between options. They may be authorizing its release.

A September 26 individual Internet-Draft on human oversight terminology separates observation, check, decision, and release. It is a work in progress, not an adopted standard or a legal requirement. Its useful contribution is the distinction: a record that someone permitted an action does not establish that they checked its correctness.

Apply that distinction to a launch workflow.

The designer approves the image crop. The PM confirms the feature description. The marketing lead authorizes delivery to a particular audience. Those are three different decisions over different parts of the work.

A single green “Approved” badge conceals the differences. A later agent could read that badge and infer permission to distribute the whole package, even though the only thing checked was the picture.

I would make the object of approval visible: this image, this email version, this recipient list, this release time. If one of those changes, the product needs to decide whether the earlier approval still applies.

That is a product rule worth writing down before the button is designed.

Give the boundary somewhere to live

On October 7, Microsoft announced general availability of Microsoft Execution Containers. Its approach lets developers declare which resources a workload can access, with the containment policy enforced outside the agent’s control. The announcement describes controls for files, networks, processes, and desktop interaction, with different containment options across platforms.

That is an infrastructure mechanism, not a complete product permission model. A container can restrict access to a resource; your application still needs to know which customer, document, amount, or destination an action concerns.

For a product team, the architectural implication is straightforward: the interface should describe a boundary the execution layer can enforce.

“Draft only” is a useful promise if the agent can create and save a draft while the send operation remains unavailable. It is a fragile promise if every operation is available and the entire distinction lives in a paragraph the model is expected to remember.

The same principle applies to design work. An agent may explore alternatives in a branch without being allowed to publish the shared component library. A research assistant may summarize interviews without being allowed to invite participants to a follow-up session.

These permissions should follow the delegated job. A person’s access to a system is usually broader than the access needed for one task performed on their behalf.

Spend attention where the consequences change

The obvious response is to ask for confirmation more often. That creates its own design problem: a product that interrupts on every routine step makes it harder to notice the step that deserves attention.

I would organize the experience around changes in consequence.

Reading a permitted source, producing a local draft, changing a shared record, and sending something outside the team deserve different treatment. The exact boundaries depend on the workflow. A read can expose sensitive information; a write can be a harmless autosave. The verb alone does not tell you enough.

Composio’s October 5 Agents @ Work snapshot makes the volume question tangible. In its classified sample for September 29–October 5, 93% of actions were reads. This is a vendor-specific sample of app calls, not a representative measure of all agent work or the proportion of actions that are safe. It illustrates why treating every tool call as an equally important approval event is a poor starting point.

Instead, define a working area in which the agent can proceed. Interrupt when it needs to cross a boundary that the current task does not cover.

For the announcement example, that might mean free movement through approved source material and draft revisions, followed by a deliberate review of the actual email and its audience before delivery.

Design the review around an action

A review screen should let someone answer four questions without reconstructing the whole conversation.

What will change? Show the finished artifact or the proposed difference. For an email, show the subject and body. For a record update, show the current and proposed values.

Where will it happen? Name the destination and environment. A test workspace and the customer-facing workspace can look almost identical.

Who is affected? Show the audience or scope. “Send the update” leaves too much hidden if it means every customer rather than the project team.

What can be undone? Explain the recovery path honestly. A saved draft can be edited. An email can be followed by a correction, but that does not make the original delivery disappear.

Then use an action label that names the decision: “Send this email to the test group” carries more information than “Continue.”

After execution, provide a receipt: what happened, which version was used, and whether it succeeded. If an external service times out, show the uncertainty. Retrying a delivery when the first attempt may already have succeeded is another product decision, not merely an implementation detail.

Three moves for Monday morning

Pick one workflow and map its authority. Take a task your team already delegates. List what the agent may read, create, change, and release. Name the point at which it needs a new decision. Include the route it should take when a required resource is unavailable.

Write one acceptance criterion for a correct stop. For example: the announcement is drafted and saved, the proposed audience is visible, and nothing is sent before release approval. An agent that stops there has completed the requested work.

Test a change after approval. Approve a draft, then change the recipient list or the content. Check what the system actually permits. Also test a failed submission with an uncertain result. The interesting behaviour often begins after the happy path breaks.

PMs can put these conditions in the requirements. Designers can make the scope and consequences understandable. Engineers can connect those promises to enforceable controls. Each discipline owns part of the same interaction.

As agents take on more execution, this becomes a larger part of product quality. Users need to know what they delegated, what remains theirs to decide, and whether the product will preserve that distinction when the task gets difficult.

Before you ask whether your agent can finish the task, define what a correctly finished task allows it to do.

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

Convert Markdown:
https://convert-markdown.com/

Skills for Product Managers:
https://github.com/julianoczkowski/product-manager

Skills for Designer:
https://github.com/julianoczkowski/designer-skills

I’m building Herdloom, a local-first workspace for coordinating coding agents. If these are problems you’re running into too, I’d be interested in your experience. You can also join the private beta.

For four and a half months, Figma’s design agent was free. On October 6, that stopped.

The agent is out of beta, and every prompt now draws from the same AI credit budget you already use for Figma Make. If Make used up your allowance this month, you could open a design file this week and find the agent sitting at zero.

I’ve tested Figma’s agent, Google Stitch and Claude Design on my channel. The price change is the least interesting part of this story. What it tells you about where design work starts, and who owns it, is the part worth your ten minutes.

What changed on October 6

The agent in Figma Design and Weave tools both moved from open beta to general availability on October 6, and both now consume AI credits. Here is what that means in practice, straight from Figma’s own FAQ:

• One budget across features. The agent draws from the same budget as Make and every other GA AI feature. Run out on one, you’re out on all of them.
• No fixed price per prompt. Credit use varies with how complex the prompt is, how many actions the agent takes, and how much context you give it, such as connected libraries or attached files.
• Seat credits didn’t change. Every seat still gets a monthly allowance that resets. Anything beyond that is an admin buying more, by subscription or pay-as-you-go.
• Beta usage was free, and it’s on record. Organization and Enterprise admins can download a CSV of how much each person used during the beta.

Figma softened the landing in advance. On August 25 it doubled the credits in Professional add-ons and gave Organization and Enterprise 1.6x more, at the same price.

The GA release itself added team guidelines the agent follows, the ability to pull other Figma files into a chat, and lower latency, according to State of AI’s write-up. Full seats on Professional, Organization and Enterprise get the agent. Starter gets a limited version.

State of AI also reports Figma’s claim that the new agent wins about 60% of the time in evaluations graded by professional designers. It doesn’t say what it was compared against. I’d hold that number loosely.

Why Figma had to do it

Figma’s Q2 numbers looked great on top and ugly underneath. Revenue grew 48% to just over $370 million, beating estimates. Cost of revenue grew 117%, mostly from AI infrastructure and hosting, and the stock closed down 14.9% the next day, per The Motley Fool.

Management was open about the cause. It was running AI features it wasn’t charging for yet, and the beta agent was one of them. Every free prompt was a cost on Figma’s side of the ledger.

People were clearly using it. State of AI reports that more than 80% of customers paying over $10,000 a year used AI credits weekly, and more than a fifth of weekly credit users only touched Figma’s AI through the agent. That second number is the important one. For those people, the agent is Figma AI.

The underlying problem isn’t unique to Figma. A seat subscription sets a predictable price. The model behind an AI feature costs money every single time someone uses it. And Figma rents that model from someone else. Usage-based pricing is one way to bring those two sides closer together. Better model routing and lower inference costs are others.

The awkward part: your supplier is now your competitor

Figma builds on models from the big labs. This year, those labs started shipping design tools of their own.

Google’s Stitch is free. Then in April, Anthropic’s chief product officer Mike Krieger left Figma’s board, and three days later Anthropic launched Claude Design. It reads a company’s codebase and design files and hands finished work to Claude Code. Figma’s stock fell 7% that day, according to State of AI. Meanwhile, Claude still powers features inside Figma’s own products.

So picture the position. You rent a model, you pay for every call to it, you can’t fully charge your customers for it yet, and the company you rent it from is selling a product that overlaps with yours.

I’ve had all three tools on camera, and they don’t do the same job. Claude Design exports HTML, not native Figma files, so a lot of work that starts there still has to land on Figma’s canvas. That gap is real, and it’s the gap Figma is betting on.

Figma’s bet: be the place every agent writes to

Figma’s response has been to open its canvas to outside agents.

In March it opened the canvas to agents through a use_figma tool on its MCP server. Claude Code, Codex, Cursor and others can now create and edit native Figma files. It also added skills: markdown files that teach an agent how a specific team builds.

The logic is simple. AI-generated design looks generic because the agent doesn’t know your standards. Your standards live in Figma: the components, tokens, variables and a decade of file history. If agents are going to do design work anyway, Figma wants to be the system of record they all write into.

The new guidelines feature applies the same idea to Figma’s own agent. Your design system stops being a library people browse and becomes a set of instructions an agent follows.

That moat only holds as long as teams keep building their systems in Figma. That’s the real bet behind this pricing change.

What this means for designers and PMs

AI is now a line item, not a feature. A seat price used to describe what you paid for. It doesn’t anymore. The more your team leans on the agent, the more it costs, and someone will start asking whether that spend is producing anything. You want to be the person with the answer.

Your design system is the product now. If agents are doing more of the making, the quality of what they make depends on the rules you give them. A team with clear guidelines, tokens and components gets on-brand output. A team that lets agents work from defaults ships something that looks like everyone else’s.

The skill is shifting from drawing screens to writing rules. This is the IC 2.0 shift I keep coming back to. Execution gets cheap. Judgment, standards and knowing what good looks like get expensive. Writing a guideline an agent can follow is a design skill, and it’s going to matter more than pixel-pushing speed.

Where work starts is the real question. If more design starts in Claude Design, Stitch or a coding agent and only reaches Figma for cleanup, Figma becomes a finishing tool. If those agents keep writing into Figma files, it becomes the system of record. Your team is already choosing one of those paths, whether you’ve decided to or not.

What I’d do this week

1. Pull the beta usage CSV. If you’re on Organization or Enterprise, your admin can download it from the AI credits dashboard. It shows who used the agent during the free period and how much. That’s a starting point for estimating usage, not a fixed quote: Figma says consumption can change.
2. Check your AI Balance. The agent draws from the same budget as Make. If you’ve used up your allowance in Make, you may have no credits left for the agent. Check your own balance and your team’s add-on arrangements before assuming the seat price covers the work.
3. Write your team’s guidelines before you scale usage. Rework costs credits too. An agent that knows your standards gets closer on the first try.
4. Run one real task three ways. Figma’s agent, Claude Design, and Claude Code writing into Figma through MCP. Compare the output, the cleanup time and the cost. Don’t trust anyone’s benchmark, including Figma’s 60%.
5. Decide where your source of truth lives. Then make sure every tool you use writes back to it.

The honest close

Figma charging for its agent isn’t a cash grab. It’s a company that rents its intelligence finally passing the meter through to the people using it. I expect more design tools that depend on outside models to face the same pressure.

The question for you isn’t whether the agent is worth the credits. It’s where your design work actually begins now, and whether your standards travel with it.

So here’s mine to you: does your design work still start in Figma, or does Figma only see it at the end? Tell me in the comments. I’m curious which way designers and PMs are really going.

I only review tools I’ve used myself. For hands-on tests of Figma’s agent, Stitch and Claude Design, find me on YouTube at AI For Work.

Sources

• Figma’s AI Agent Was Eating Its Margins, State of AI, October 7, 2026
• AI credit updates FAQ, Figma Help Center
• Why Figma Stock Just Sank, The Motley Fool, August 6, 2026
• The Figma canvas is now open to agents, Figma blog

Illustrations generated with GPT Image.

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel.

YouTube · LinkedIn · GitHub

In mid-July, developer Peter Steinberger posted a single line on X asking whether we were still talking about loops or had shifted to graphs. Within two days “graph engineering” was trending, and within the same 48 hours it already meant at least three different things depending on who you asked: multi-agent orchestration graphs, networks of self-improvement loops, or knowledge graphs as agent memory.

I have watched this cycle before. Prompt engineering in 2023. Context engineering in 2025. Loop engineering in June. Now this. The labels rotate roughly every season, and every rotation produces a wave of people arguing about the word instead of reading the evidence.

Here is the thing though. On this particular question, loops versus graphs, single agents versus networks of them, the evidence actually exists. Anthropic published production data. Cognition published a counter-argument from shipping Devin. A Berkeley-led team published a peer-reviewed failure analysis of over a thousand multi-agent runs at NeurIPS. The debate that is currently generating hot takes was substantially settled before the buzzword existed.

This article is a tour of that evidence. What a loop is, what a graph is, what the research says about when each one wins, and where the actual bottleneck sits. No hype, and no claims beyond what the sources support.

First, the vocabulary

Anthropic’s “Building Effective Agents” guide, published in late 2024 and still the most cited primer in the field, draws the distinction cleanly. Workflows are systems where models and tools follow predefined code paths. Agents are systems where the model dynamically directs its own process, deciding what to do next based on what just happened.

The simplest agent is a loop: act, observe the result, check it against some standard, and repeat until done. That shape is ancient. It is the thermostat, the PID controller, plan-do-check-act. The only new part is that the thing inside the loop can now read code, use tools, and judge its own output.

How much does that loop matter? Andrew Ng answered with numbers back in March 2024, before any of the current vocabulary existed. On OpenAI’s HumanEval coding benchmark, GPT-3.5 prompted zero-shot solved 48.1 percent of the problems and GPT-4 solved 67.0 percent. But GPT-3.5 wrapped in an iterative agent loop reached up to 95.1 percent. Ng’s conclusion, in his own words: the improvement from GPT-3.5 to GPT-4 is dwarfed by incorporating an iterative agent workflow. A weaker model inside a good loop beat a stronger model without one, and the gap was larger than a full model generation. In the same post he named four design patterns for agentic systems: reflection, tool use, planning, and multi-agent collaboration. Read that last one again. The most cited AI educator in the world listed multi-agent collaboration as a core pattern more than a year before anyone said “graph engineering.” The idea is not two weeks old. Only the label is.

A graph is what you get when one loop is not enough. Multiple units of work, called nodes. Routes between them, called edges, some of which are conditional: if the output fails, go here; if it passes, continue there. And shared state flowing through the whole system. None of this is new either. LangGraph has had nodes, edges, and state as its core primitives for years, and Microsoft’s AutoGen added graph-based orchestration to its multi-agent framework well before anyone said “graph engineering.” The term is new. The practice has documented lineage.

So the real question is not what a graph is. It is when a graph beats a loop. And on that, we have data pointing in two directions at once.

The case for graphs: Anthropic’s 90.2%

In June 2025, Anthropic published the engineering write-up behind Claude’s Research feature, and it remains the strongest documented result for multi-agent systems in production.

The architecture is an orchestrator-worker graph. A lead agent reads the query, plans, and spawns several specialized subagents in parallel, each with its own context window, each chasing one independent thread. A synthesis step pulls the findings together. On Anthropic’s internal research evaluation, this system, with Claude Opus 4 as the lead and Claude Sonnet 4 subagents, outperformed a single-agent Claude Opus 4 by 90.2 percent.

Two details from that write-up matter more than the headline number.

First, why it works. Anthropic’s analysis found that token usage alone explained about 80 percent of performance variance on their browsing evaluation. Multi-agent systems win largely because they let you spend more thinking in parallel: separate context windows working simultaneously add reasoning capacity a single window cannot match. Parallel subagents plus parallel tool calls cut research time by up to 90 percent on complex queries.

Second, the price and the boundary. The same write-up reports that multi-agent systems burn roughly fifteen times the tokens of a normal chat, and it is blunt about fit: domains that require all agents to share the same context, or that involve many dependencies between agents, are not a good fit for multi-agent systems today. Anthropic even published scaling guidance, with simple fact-finding assigned to one agent and a handful of tool calls, and only genuinely complex research justifying ten or more subagents.

Read carefully, the strongest pro-graph result in the field comes with its own warning label. Graphs win on breadth-first problems that decompose into independent parallel threads, where the value of the answer justifies a fifteen-fold cost. That is a real class of problems. It is not most problems.

The loop-to-graph trajectory got its most visible demonstration this March, from Andrej Karpathy. As Fortune reported, the former OpenAI founding employee and Tesla AI lead put a coding agent to work improving the training of a small language model, let it run continuously for two days, and watched it conduct 700 experiments and discover 20 optimizations that produced an 11 percent training speedup. He called the system autoresearch, and it is a textbook single loop: one agent, one file it can modify, one objective metric, repeat until time runs out. What matters for this article is what he said next. Karpathy wrote that the next step is for autoresearch to become massively collaborative across agents, because the goal is not to emulate a single PhD student but a research community of them. That is the loop-to-graph transition stated by one of the field’s most followed researchers, after publicly hitting the ceiling of a single loop. Worth noting: a wave of viral posts and unofficial “papers” has since attached Karpathy’s name to claims he never made, so treat anything beyond his own posts and the reporting on them with suspicion.

The case against: Cognition and the game of telephone

Days after Anthropic’s post, Walden Yan of Cognition, the team behind the coding agent Devin, published an essay titled “Don’t Build Multi-Agents.” The timing made it look like a feud. It reads better as the other half of the same finding.

Cognition’s argument is about context. When you split a task across multiple agents, each one works from a fragment of the picture, and critical information gets lost in the handoffs. Parallel agents make implicit, conflicting choices about style and edge cases. When two human engineers produce a merge conflict, they talk it out and reach consensus. Yan’s point is that agents cannot yet sustain that kind of long-context negotiation reliably, so conflicts compound instead of resolving. His prescription: default to a single-threaded agent, invest in context engineering, which he calls the number one job of engineers building agents, and hold multi-agent designs to a high bar.

Notice this is not actually a contradiction of Anthropic. Coding is close to a worst case for the fit criteria Anthropic themselves published: it is dependency-heavy and demands shared context. Research is close to a best case: independent parallel threads, results merged at the end. The two most cited essays in this debate agree on the boundary and differ mainly in which side of it their product lives on.

Yan updated his position this April, ten months on, and the refinement is worth quoting because it is the most practical single sentence in the entire discourse: multi-agent systems work best today when writes stay single-threaded and the additional agents contribute intelligence rather than actions. Many readers, many advisors, one writer. That is a graph, but a disciplined one.

The referee: what 1,600 failure traces show

Between the two vendor perspectives sits the academic evidence, and it is sobering.

A Berkeley-led team published “Why Do Multi-Agent LLM Systems Fail?” with a dataset of over 1,600 annotated execution traces collected across seven popular multi-agent frameworks. Their opening observation cuts through most of the current hype on its own: despite the enthusiasm, the performance gains of multi-agent systems on popular benchmarks are often minimal.

From those traces they built MAST, the first empirically grounded taxonomy of multi-agent failures: fourteen distinct failure modes, clustered into three categories. Specification and system design issues. Inter-agent misalignment, which is Cognition’s telephone game showing up in the data. And task verification, meaning the system’s checks failed to catch bad work before it propagated.

Their conclusion is the most important sentence in this article, so I will keep it plain: the failures they identified often stem from system design issues, not from model limitations. Weak role definitions, vague specifications, and verifiers that rubber-stamp instead of verifying. Wiring more agents together does not fix any of that. It multiplies it.

If you want one image for the whole finding, it is this: a graph of weak loops is just slop produced in parallel, faster and at fifteen times the cost.

What the evidence converges on

Put the three sources side by side and the disagreement mostly dissolves. What remains is a short list of positions all of them support.

Start with the simplest thing that works. This is Anthropic’s own advice in the guide everyone cites: find the simplest solution possible, and only add complexity when it demonstrably improves results. A single job with a single clear check is a loop and should stay one.

Verification is the bottleneck, not architecture. One of MAST’s three failure categories is verification outright, and the design flaws in the other two are exactly what a strict check would have caught. Whether you run one loop or fifty, the component that decides “is this good enough to proceed” determines what the whole system produces. This is also why the graph conversation should feel familiar to anyone who has written acceptance criteria for a living: a verifier is a definition of done that executes.

The known shapes are few, and they are documented. Anthropic’s guide lays out five composable patterns: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. The production systems in the evidence above are assemblies of these five, plus one addition every serious source insists on: a human approval gate in front of anything irreversible. You do not need to invent structures. You need to recognize which one, if any, the problem in front of you requires.

The fit test is published. Graphs earn their cost when the work decomposes into genuinely independent parallel threads, when the value of the outcome exceeds a token bill an order of magnitude higher, and when writes can stay single-threaded while extra agents contribute judgment rather than actions. Fail any of those tests and the evidence says stay with a loop.

Why this is not just an engineering story

I write for designers and product managers, so let me say the part the engineering coverage skips.

Strip the code away and look at what the scarce skill actually is across all three sources. Anthropic’s write-up describes the hard work as deciding how to decompose tasks, how much effort each subagent deserves, and where the boundaries sit. Cognition describes it as curating exactly what context each worker needs. MAST describes the dominant failure source as bad specifications and bad checks. None of that is typing code. All of it is structural judgment: what runs, in what order, checked against what standard, escalated to whom.

This is the shift I keep describing as Individual Contributor 2.0. As AI absorbs execution, the durable professional skills concentrate in judgment, orchestration, and pattern recognition. The graph engineering discourse, once you subtract the buzzword, is the clearest evidence yet that this is where the field is heading. Nodes, edges, and state are boxes, arrows, and annotations. Verifiers are acceptance criteria that run. The people who have spent careers drawing flows and defining done are closer to this discipline than the discourse gives them credit for. What is new is only that the diagrams now execute, fail, and cost money, which is precisely why the design of them finally matters this much.

The honest close

The word will probably fade. The pattern of the last three years says a new label arrives within months, and the same people will argue about that one too.

But the evidence assembled here does not fade with the label. A production system that beat its single-agent baseline by 90 percent on the right problem shape. A shipped counter-example showing why the wrong problem shape produces fragile systems. A peer-reviewed taxonomy showing that when these systems fail, it is usually the design and the verification that failed, not the model.

That is not a trend. That is a discipline forming in public, with its boundaries already measured. You can spend the next month debating the buzzword, or you can read the primary sources listed below, learn the patterns, and practice the one judgment call all the evidence agrees on: knowing when the answer is “this does not need a graph at all.”

Sources

• Andrew Ng, X post on agentic workflows and the four design patterns, March 2024 (x.com/AndrewYNg/status/1770897666702233815), expanded in his Sequoia AI Ascent 2024 talk
• Anthropic, “Building Effective Agents” (anthropic.com/engineering/building-effective-agents)
• Anthropic, “How we built our multi-agent research system” (anthropic.com/engineering/multi-agent-research-system)
• Walden Yan, Cognition, “Don’t Build Multi-Agents” (cognition.com/blog/dont-build-multi-agents) and the April 2026 follow-up “Multi-Agents: What’s Actually Working”
• Cemri, Pan, Yang et al., “Why Do Multi-Agent LLM Systems Fail?” (arXiv:2503.13657, NeurIPS 2025)
• Jeremy Kahn, Fortune, “‘The Karpathy Loop’: Former OpenAI researcher’s autonomous agents ran 700 experiments in 2 days” (fortune.com/2026/03/17/andrej-karpathy-loop-autonomous-ai-agents-future/)

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

Convert Markdown:
https://convert-markdown.com/

Skills for Product Managers:
https://github.com/julianoczkowski/product-manager

Skills for Designer:
https://github.com/julianoczkowski/designer-skills

An agent handed me a 3,000 word implementation plan. It was correct. The reasoning held up, the risks were listed, the sequencing made sense. I pasted it into Slack for two engineers and a PM.

Nobody read it.

Not because the thinking was weak. Because the plan had shape, and markdown flattened it. Three candidate approaches that needed to sit side by side became three sequential walls of text. A timeline became a bulleted list. A risk matrix became indented rows the reader has to reassemble in their head.

That is not a writing problem. It is a format problem, and it has a specific cause.

Markdown won for machine reasons

John Gruber designed markdown in 2004 so that a plain text file would stay readable as-is and convert cleanly to HTML. That second half is the half that survived into 2026, and it survived for reasons Gruber was not designing for.

Markdown is cheap in tokens. Its structure is unambiguous. It parses trivially. Models were trained on oceans of it, so they emit it without being asked. It is the closest thing we have to a shared language between a model and a file system. Agent instructions, skills, repo docs, tool outputs, memory files: all markdown, and correctly so.

For machine to machine, markdown is the right default. The problem starts the moment a human is on the receiving end.

Markdown has exactly one axis

Every markdown document runs in one direction: down. Headings, bullets, tables, code fences are all stops on a single vertical line. You scroll, you hold the earlier part in working memory, you scroll back when you lose it.

For prose, that is fine. Prose is linear. Argument is linear.

It fails for three kinds of content that show up constantly in real work:

Comparative. Options, trade-offs, before and after, model A against model B. Comparison requires adjacency. Markdown gives you sequence, so the reader has to do the adjacency themselves.

Spatial. Architecture, data flow, a call graph, a timeline, a state machine. These are pictures. A nested bullet list is a picture that has been dictated over the phone.

Interactive. Anything the reader needs to sort, filter, toggle, reorder, or feel. Forty rows of tickets. A motion curve. A set of feature flags with dependencies.

Thariq Shihipar named this precisely in The unreasonable effectiveness of HTML: markdown flattens information that is inherently spatial, comparative, or interactive, and a small HTML file fixes it. That observation is the premise of everything below.

The real question is producer versus consumer

Here is the frame I have started using, and it resolves the argument faster than any debate about formats.

The format should be chosen by whoever consumes the artifact. Not by whoever produced it.

Four combinations, and only one of them is a problem.

Agent to agent. Markdown, JSON, YAML. Correct, and getting more correct every month.

Human to agent. Markdown. Also correct. Prompts, skills, repo docs, memory files.

Human to human. Whatever the team already opens. Mostly self-correcting, because the producer knows the reader.

Agent to human. Rich text, HTML, a PDF, a real document. This is the broken one, and it is now the most common transaction in knowledge work.

Three of those four are already handled.

What happens in practice is that we ship the producer’s working format to the consumer, because that is simply the file that came out of the process. The agent’s scratchpad becomes the deliverable. We paste the raw output into Slack, attach the .md to a ticket, drop it in a shared folder, and then quietly wonder why the feedback is thin and the decisions do not move.

The reader is not being lazy. They were handed a serialization format and asked to do the rendering in their head.

Why this broke now specifically

Two things changed at the same time.

Volume stopped being self-limiting. Writing used to constrain length. If a plan took four hours to write, it got edited down, because the writer was the first person who had to reread it. An agent produces 3,000 words in nine seconds and feels nothing. The cost of generating structure collapsed, and the cost of reading it did not move at all.

The packaging layer thinned out. There used to be somebody between you and the reader. A technical writer who turned your notes into a doc. A designer who made the deck. An analyst who built the chart. Those roles have not vanished, but they sit on far fewer handoffs than they did five years ago.

Which means you are now the last human before the artifact reaches its audience. Nobody downstream is going to reformat it for you.

What HTML actually buys you

HTML is not the fancy option. It is the format that already has the primitives the work needs: two columns, a sortable table, a collapsible section, a tab strip, an inline SVG, a slider, a drag handle. No build step, no dependencies, one self-contained file you can open in a browser, mail to a colleague, or drop into a DM.

I packaged this as an agent skill so my tools produce it by default when the content warrants it. It lives at github.com/julianoczkowski/html and installs with one command. Twelve patterns, each one a different shape: options, plan, status, explainer, deck, editor, diagram, table, PR writeup, codemap, design tokens, motion. The routing is plain language, so asking for “my options for X” produces the options artifact without naming it.

Two conventions in there matter more than the rest.

Every artifact is a single file. State lives in memory and dies on refresh. That is a feature. These are disposable. Nobody is maintaining them.

Every interactive artifact exports back to text. Drag thirty tickets into Now, Next, Later, Cut, then press one button and get markdown back out. The artifact is throwaway; the export is the durable output, and it goes straight back into the agent. The loop returns to the machine format on purpose.

When markdown is still the right answer

I want to be straight about this, because format evangelism gets silly fast.

Markdown is correct for prose without shape. An email. A paragraph of analysis. A commit message. A README. Meeting notes that are genuinely just notes. Anything an agent reads next.

The test is one question: does this content have shape? If it is sentences, markdown is already the right surface and an HTML artifact is decoration. Turning a paragraph into a dashboard is not a workflow improvement, it is a waste of everyone’s afternoon.

Most content does not have shape. The content that does, has it obviously.

This is what IC 2.0 looks like in practice

My working thesis is that as AI absorbs execution, the scarce professional skills become judgment, orchestration, and pattern recognition. Format choice is one of the cleanest examples I have found of what that actually means day to day.

Producing the content is now free. Deciding who reads it, what they need to do with it, and which surface they will open it on is not free, and no model will make that call for you, because the model cannot see your org.

That judgment is accumulated, not innate. You know a 3,000 word markdown plan will die in Slack because you have watched one die. You know the exec wants a one page PDF and the staff engineer wants the annotated diff and the PM wants the options side by side, because you have handed all three the wrong thing at some point. That is pattern recognition, and it is falsifiable, which is exactly why it holds value.

The IC 2.0 worker crosses more function boundaries than the IC 1.0 worker did, because AI collapsed the roles that used to sit between them. Cross more boundaries and format stops being a formatting concern. It becomes the handoff itself.

Two moves for Monday morning

At generation time, if the content has shape, have the agent produce a single HTML file instead of a markdown wall. That is what the skill is for.

At handoff time, you will still have markdown, because markdown is what agents emit and what half your files already are. So convert it into whatever the reader opens.

That is why I built free Convert Markdown app. Paste markdown or drag in your .md files, pull them from Google Drive, GitHub or a URL, pick a document style, and take it out as:

• Rich text on the clipboard, ready to paste into Docs, Word, Notion or an email
• A multi-page PDF with real page breaks and vector text
• A native Word .docx
• A standalone styled .html file
• A fully formatted Google Doc, created directly

Multiple files open as tabs and can be merged into one document with page breaks between them. Everything runs in the browser: pasted text and uploaded files are processed locally and never stored on a server, which matters when the markdown in question is a client document.

Then do the boring version of the work. Pick the three handoffs you repeat most often, a weekly status, a PR writeup, an options doc, and decide once who consumes each one. Fix the format for those three. Leave everything else alone.

The question was never markdown or HTML.
It is: who opens this, and what do they need to do with it.

Answer that first and the format picks itself.

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

Convert Markdown: https://convert-markdown.com/
Skills for Product Managers: https://github.com/julianoczkowski/product-manager
Skills for Designer: https://github.com/julianoczkowski/designer-skills

Most AI product tools do one of two things. They give you a chat window and hope you know what to ask, or they hand you a single template and call it a workflow. Neither one teaches you the market-driven way to build a product. Neither one keeps the thread from an idea all the way through to launch.

So I built PM Copilot: the Pragmatic Institute framework, operationalised as 18 Claude skills. One router plus 17 stage skills. Each skill is a slash command. Each command produces a real deliverable, a Markdown or Word document, that becomes the input to the next stage. You do not get scattered outputs. You accumulate an ordered dossier, one folder per feature, numbered from 01 onward.

The same skills/ folder runs in Claude Code, Claude Desktop, and Cursor. It ships as an Agent Skills bundle packaged as a Claude Code plugin.

A quick disclaimer up front: this is an independent tool that operationalises the publicly described Pragmatic Framework for practitioners. It is not affiliated with, endorsed by, or sponsored by Pragmatic Institute. “Pragmatic Framework” and “Pragmatic Institute” are trademarks of their respective owner.

Now let me explain what it actually does, who it is for, and why I think this shape of tool is where knowledge work is heading.

Why I built this

Here is the failure mode PM Copilot is designed to kill.

A product manager has an idea. They open a blank doc, or a chat window, and they write a PRD. The PRD describes a solution. It lists features. It never establishes that the problem was real, urgent, or something the market would pay to solve. Development reads it, builds it, and six months later nobody uses the thing. The autopsy always finds the same cause of death: the team started at the solution instead of the market problem.

The Pragmatic framework exists to prevent exactly this. It forces you to work outside-in: market problems first, then who they belong to, then how you win, then what you build, then how you launch. The method is well proven. The trouble is that in day-to-day practice, most people skip the front half because it is slow and unglamorous, and jump straight to the artifact that feels like progress.

AI changes the economics of that. The slow, unglamorous front half, the discovery notes, the persona evidence, the competitive matrix, the positioning statement, is exactly the kind of structured drafting that a well-scoped skill can execute in minutes. So the question stopped being “do I have time to do this properly” and became “do I have the judgment to direct it and check it.”

That is the whole thesis of PM Copilot. AI handles the execution. You supply the judgment, the evidence, and the decision at each gate.

Who this is for

This is for individual contributors, not just managers with a Pragmatic certificate on the wall.

If you are a product manager, PM Copilot is the obvious fit. But it is built for the wider set of people who now own product outcomes without a big team behind them: the designer who has to justify a feature to leadership, the founder who has to size a market and make a buy-build-partner call, the engineer-turned-owner who has to write requirements that development will not misread.

If you have ever been handed the responsibility for an outcome and told to “figure out the product side,” this is for you. You do not need to have memorized the 37 boxes of the framework. The router figures out where you are and routes you to the right stage.

The framework, in five stages

The Pragmatic framework maps into five stages, and PM Copilot follows that order because the artifacts compound. A Market Problems Table feeds Positioning. Positioning feeds Strategy. Strategy feeds the PRD. The PRD feeds the Launch Plan. Work them in sequence and each output makes the next one sharper.

The five stages are Router, Foundations, Focus, Build, and Go-to-market. Here is what each stage is for, and every skill inside it.

Router: one entry point that reads your intent

/pm-copilot is the entry point. It detects what you are asking for, tells you where you are in the framework, and routes you to the right stage. Ask it "I want to build a feature" and it does not just spit out a PRD. It runs you through the right sequence, or drops you at the exact stage you actually need. Use this when you are not sure where to start, which is most of the time. It orchestrates the journey and produces no artifact of its own.

Foundations: understand the market before you build anything

This is the front half that everyone skips and nobody should. Seven skills.

/market-problems discovers and validates problems that are urgent, pervasive, and worth paying to solve. It covers who to interview, observation versus interview, and the NIHITO rule (Nothing Interesting Happens In The Office). Use it first, always. It delivers a Market Discovery document plus a scored Market Problems Table. Everything downstream traces back to this.

/win-loss-analysis helps you understand why buyers chose you, or chose a competitor, by examining the buying process rather than blaming the salespeople. It enforces the rule that win/loss is run by an objective party not involved in the sale. Use it when deals slip, when you are churning, or when you keep losing to the same rival and cannot say why. Delivers an Interview Guide and a Findings Report.

/distinctive-competence pins down what your organization can do that rivals cannot: abilities that are valued, different, and provable. Use it when you need to answer "what actually makes us different" with something stronger than a slogan. Delivers a Distinctive Competencies worksheet.

/competitive-landscape maps competitors and alternatives, then helps you decide when to fight and when to run, plotting the Solution Matrix of customer impact against depth of investment. Use it before you commit resources to a market you might not win. Delivers a competitive analysis and a Solution Matrix.

/personas builds evidence-based buyer and user personas, and it insists these are usually two different people. The person who buys is rarely the person who uses. Use it so the whole team stays connected to real humans instead of a demographic average. Delivers a Buyer Persona and a User Persona.

/positioning describes the product by the problems it solves, not the features it has, in a statement of 25 words or fewer, backed by a problem-oriented capabilities worksheet. Use it when you need everyone from sales to engineering to describe the product the same way. Delivers a Positioning Document and a POC worksheet. This is the signature artifact of the Foundations stage.

/gap-analysis scores your team across all 37 framework activities to find the biggest gaps and where to invest first. Use it as a maturity check, a where-do-we-stand self-assessment. Delivers a Gap Analysis table and a top-three action plan.

Focus: turn what you learned into a defensible strategy

Four skills that convert market knowledge into decisions.

/product-strategy forces the who-to-win by what-to-build choice with the Strategy Matrix, and compares the product team's view against leadership's so you surface misalignment early instead of at the worst possible moment. Use it when the roadmap is spread too thin and you need to pick. Delivers a Strategy Matrix and alignment notes. This is the signature artifact of Focus.

/opportunity-scoring ranks competing opportunities objectively across competency fit, competitive landscape, investment level, and buyer impact. Use it when you are choosing between good ideas and want a defensible answer instead of the loudest opinion. Delivers an Opportunity Scorecard.

/product-canvas builds the business case: value proposition, value creation, value capture, market sizing, the buy-build-partner decision, and a go/no-go recommendation with quantified risk. Use it when you need buy-in from leadership or need to justify the investment. Delivers a Product Canvas and Business Case.

/product-roadmap communicates vision, direction, and priorities over time, framed as a plan, not a commitment. It keeps roadmap and release plan properly separate. Use it to align stakeholders on direction without accidentally promising dates. Delivers a Product Roadmap.

Build: define and deliver the product

Five skills. This is where most people wrongly start. In PM Copilot it comes fourth, on purpose.

/requirements turns validated problems into prioritized market requirements, each written as "[persona] has [problem] with [frequency]," and prioritized as Priority = Market Evidence multiplied by Impact. Use it when development keeps saying the requirements are not specific enough. Delivers a Market Requirements Document.

/use-scenarios puts each problem into a day-in-the-life story so the team cannot misread it, keeping the What separate from the How. Use it to reframe a feature request as the real underlying problem. Delivers a Use Scenarios document.

/prd assembles personas, problems, requirements, and scenarios into the full specification the team builds from. Use it when the discovery is done and you need to put it all together. Delivers a Product Requirements Document. This is the signature artifact of Build.

/release-plan commits an increment: MVP scope done right, themes, estimation, the market window, and sign-off. Use it to turn a prioritized backlog into a dated, committed release. Delivers a Release Charter.

/stakeholder-communication keeps everyone aligned using the Influence by Importance matrix, a communications plan, and status updates that expose risk early rather than hiding it until the review. Use it to stop surprises from reaching leadership late. Delivers a Stakeholder Communication Plan and a Status Update.

Go-to-market: launch the market-driven way

One skill, and it is the one people underestimate most.

/launch-plan plans a launch where readiness is more than product readiness: messaging, sales enablement, demand programs, a readiness checklist, and success metrics. Use it so the launch does not become "we shipped and told nobody." Delivers a Launch Plan and Readiness Checklist.

The artifacts are the point

Every stage ends in a document. The first artifact of a session creates a folder named after your feature, and every subsequent artifact lands there, numbered in order. You end up with a complete, ordered dossier, not a pile of loose files. Every document carries the same header: company, feature, author, date, collected once and reused.

You choose Markdown or Word at each step. The Word file is produced natively by whatever host you are running in, so there is no bundled converter and nothing extra to install. Markdown stays the source of truth. If an environment cannot write Word, the skill hands you polished Markdown and tells you so rather than faking a file.

That artifact chain is what makes this a workflow instead of a chatbot. The output of one skill is the literate input to the next.

Why this shape of tool is where the work is going

I want to zoom out, because PM Copilot is a concrete example of a shift I think matters for everyone doing knowledge work right now.

For most of the last decade, the scarce thing was execution. Could you write the doc, build the deck, run the analysis, produce the artifact. The person who could produce more, faster, won.

AI collapses that. Producing the artifact is no longer the bottleneck. A well-scoped skill will draft a positioning document, a competitive matrix, or a requirements doc faster than you can open the template. So the scarce skills move up the stack. They become judgment, process, and orchestration. Knowing which stage you are actually at. Knowing what evidence a claim needs before you trust it. Knowing when to fight and when to run. Sequencing the work so each output makes the next one stronger. Owning the decision at each gate.

That is the individual contributor 2.0 pattern. The modern IC operates with more autonomy, broader skills, and higher leverage than before, because AI absorbs the execution and hands back the parts that need a human. It is not about doing more work. It is about owning the outcome and directing the machine that does the work.

PM Copilot is that idea made literal. The skills do the drafting. The framework supplies the process. You supply the market evidence and the go/no-go. The whole thing is structured so the leverage lands where a person adds value: the judgment between the stages, not the typing inside them.

If you build products, or you have quietly become the person responsible for the product side without the title, this is worth an afternoon. Start at /pm-copilot, tell it what you are trying to do, and let it route you.

Try it

The full project, install instructions for Claude Desktop, Claude Code, and Cursor, and all 18 skills are on GitHub: github.com/julianoczkowski/product-manager

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski