How Conductor Turns AI From a Feature Into a Workflow

When we first added generative AI to ProdPad, we did what almost everyone did: we found useful places to put an AI feature. Summarise some feedback. Help write a description. Suggest ideas. Answer a question about the data already on the screen.

Those features were useful, and some still are. But they all stopped just before the difficult bit. The user still had to understand the process, find the right context, decide what should happen next and turn the generated output into an action.

We had added AI to the interface without really changing the work.

That gap is why we built Conductor. We stopped asking, “Where can we add AI?” and started asking, “What is the user actually trying to get done, and where can AI help without taking over the parts that still require judgement?”

An AI feature helps with a task; a workflow gets somewhere

A summariser may save a product manager ten minutes. A drafting tool may make the blank page less intimidating. A chatbot may help someone find information without learning where it lives in the product.

The limitation is that the user remains responsible for carrying the process between those moments. They decide which context matters, move information from one part of the product to another, check whether the output is valid and remember which part of the work has already been completed.

This explains why many AI features feel impressive at first but less transformative after a few weeks. They reduce effort around a task while leaving the surrounding workflow untouched.

The difference is not simply that a workflow contains more steps. It has state, authority and a definition of success. It also includes the points where the user should make a decision rather than delegate one.

Why we did not build one large product-management agent

The obvious alternative was to give one agent a much larger job. It could analyse feedback, identify opportunities, create ideas, recommend priorities and update the roadmap.

That sounds efficient until you look at what has been combined. Finding relevant evidence is different from interpreting it. Suggesting an idea is different from deciding that it deserves investment. Drafting an explanation is different from changing the roadmap that other people rely on.

Each part requires different context, tools and authority. Combining them inside one open-ended agent loop makes the result harder to inspect and much harder to test.

So the question behind Conductor was not how much autonomy we could give the model. It was what outcome the user was trying to reach, and how AI should participate in each part of that journey.

We moved responsibility for the workflow out of the model

ProdPad Conductor keeps track of the workflow while models perform smaller pieces of work where probabilistic reasoning is useful.

It can interpret the user’s intent, select the relevant workflow, gather the necessary context and decide which tools are permitted for the current step. The model may classify, synthesise or draft, but it does not have to remember every business rule or infer the entire state of the product from a chat transcript.

This separation is important. A model is very good at making sense of an ambiguous request. It is a much less reliable place to store the definitive answer to whether an onboarding step has already been completed or whether a particular action is allowed.

The workflow belongs in software. The model participates in it.

Conversation history is not workflow state

A chat transcript can suggest what happened, but it is a poor source of truth for the state of a product.

The user may have created a product in the interface, added feedback in another tab or returned to the workflow after somebody else changed the account. They may have skipped an optional branch, or completed a requirement in a way the original conversation did not anticipate.

Conductor reconciles what the user says with what has actually happened in ProdPad. It can recognise that an entity now exists, that a required field has been completed or that the next valid action has changed.

This lets the user move naturally between conversation and interface. They do not have to perform every action through the AI simply to keep it informed.

Completion needs a rule, not a conversational impression

Generic assistants often decide that a task is finished because the exchange sounds finished. That is not enough when the next step depends on whether something actually changed in the product.

In Conductor, completion can be tied to a successful tool result, the existence of a product entity, the presence of one of several acceptable fields or a valid choice made by the user. The system can also recognise completion from account state when the work happened outside the conversation.

The model still helps make the interaction flexible and understandable. It does not get the final say over whether the goal has been met.

Planning, gathering, synthesis and action are different jobs

We also separated the stages that are often hidden inside a single agent prompt.

First the system has to understand what the user is trying to do. It may then need to identify and gather relevant information, calculate or compare something, synthesise the result and prepare a recommendation. Only after those steps should it decide whether an action is both necessary and authorised.

Different stages can use different models and tools. A bounded classification may not need the same model as a difficult synthesis. A read-only step should not inherit the authority required by a later execution step. A recommendation can be useful without being automatically applied.

It is a little less magical on the architecture diagram. It is considerably easier to understand when something goes wrong.

Validation, retry and repair are part of the experience

Models sometimes omit a required field, use an invalid value or fill an optional argument with an empty default. In a demo, somebody changes the prompt and runs it again. In a product, the system has to deal with the output it received.

We validate structured output before it reaches a tool, remove meaningless arguments, check identifiers and reject actions that are not valid for the current workflow state. Where appropriate, Conductor can ask the model to repair a response or retry the step without starting the whole workflow again.

The user should not have to understand that any of this happened. They should simply experience fewer dead ends and fewer occasions where the AI confidently claims to have completed something it did not complete.

Authority should follow the workflow

A planning step may only need to read context. A data-gathering step may call search or calculation tools. An execution step may update a limited set of fields. A consequential decision may always require explicit approval from the user.

Giving each step only the authority it needs is a more robust control than giving one agent broad access and surrounding it with instructions about responsible behaviour.

It also better reflects product management itself. AI can reduce the effort involved in gathering evidence and preparing a decision, but the product team still owns the difficult choices about value, priority and direction.

Testing realistic paths rather than a perfect script

Real users do not cooperate with a carefully written conversational script. They ask questions in the middle, skip ahead, change their mind, complete work in the interface and occasionally select an option that is no longer valid.

We therefore test Conductor with scenarios rather than expecting exact phrases. Can the ideal path complete successfully? Can the user add another initiative rather than accepting a generated one? Can they move directly to feedback? Can the correct step reopen after progress elsewhere in the product?

The language may change between runs. What we care about is whether the account reaches the correct state and whether the system behaves sensibly when it cannot.

What workflow-native AI feels like

Most of this architecture should be invisible to the user. The visible result is that the AI remembers what has actually been done, asks fewer repetitive questions, appears at the point where it can help and returns decisions to the user at the right time.

The output also stops being trapped in a chat transcript. It can become part of the product because the workflow knows what the output represents and what valid action follows from it.

This has changed the way we think about building AI into ProdPad. We no longer begin with a list of AI features. We begin with the work: where context is scattered, where people lose time, where judgment matters and where a bounded model task can remove friction without taking over the decision.

The workflow is where enterprise control becomes real

Enterprise buyers increasingly talk about a trust boundary around data, traces, evaluations, memory and feedback.. That boundary only becomes real when it is expressed through the workflow. It must determine what context each step can retrieve, which model can see it, what actions are permitted and what gets retained as organizational learning.

ProdPad Conductor keeps that control outside any single model. The product’s workflow state, permissions, completion rules and accumulated context remain part of ProdPad rather than becoming an opaque property of whichever model happens to answer the next request.

This also makes model choice real rather than decorative. Supporting several APIs is not enough when the workflow itself is buried in provider-specific prompts and agent behaviour. ProdPad Conductor keeps the product knowledge and workflow in ProdPad; the model is the replaceable part.

Conductor is the workflow layer

Conductor coordinates the user’s intent, the state of their work, the relevant product context, the available models and tools, the business rules and the interface actions that can follow.

That is how we move from AI that performs an isolated trick to AI that participates in product management. It is not about placing a chatbot beside the workflow or asking one agent to improvise it. It is about making the workflow itself aware of where AI can help and where it should stop.