Why Companies Automate the Wrong Processes—and How to Find the Right AI Workflow

Companies start automation with the wrong question

Discussions about AI adoption often begin with technology. A team decides which model to use, which agent to build, which systems to connect, and which tasks to assign to it.

Executives want to know where savings can appear fastest. Technical teams compare platforms and integration approaches. Process participants suggest automating the activities that feel most time-consuming. These questions matter, but they arrive too early.

Before choosing an AI agent, a company needs to answer more basic questions:

• How is the process performed today, rather than how the procedure says it should work?
• Which people, systems, and documents take part?
• Where do delays and manual handoffs occur?
• What information is required for each decision?
• Which exceptions are absent from the instructions?
• Where are the accountability boundaries between participants?
• What does a concrete and verifiable process outcome look like?

Without this picture, a company risks automating the most visible task rather than the actual bottleneck. A product team may try to accelerate coding even though most delays happen earlier, during task definition and requirements alignment.

The documented process rarely matches the real one

In a procedure, a workflow appears sequential: one participant completes a stage, hands the result to the next, and every decision is recorded in the designated system. Real work is more complicated.

Tasks and statuses live in Jira. Requirements and architecture decisions are stored in Confluence. Implemented changes appear in GitHub. Some agreements are made in meetings. Supporting materials remain in documents, while certain exceptions exist only in the memory of experienced employees.

A formal process shows how work is supposed to happen. Digital traces show individual facts: who changed a task, when a pull request appeared, or which page was updated. Neither source explains the complete workflow on its own.

An interview alone is not enough. A participant can forget a rare exception, omit a habitual manual step, or describe the process as it should work. Familiar actions can become so automatic that people stop seeing them as separate stages.

System data alone is not enough either. It reveals events but not always their causes. Task history may show several status changes without explaining why the task returned to an earlier stage. A calendar confirms that a meeting occurred, but not which decision was made or where it was documented.

What happens when a poorly understood process is automated

When a company moves to implementation too early, the problems surface during the pilot:

• A visible individual task is automated instead of the true process bottleneck.
• The agent receives a task but cannot see related decisions, constraints, and change history.
• Rare but important exceptions appear only after the pilot produces errors.
• Automation accelerates a stage that is unnecessary or should not exist in its current form.
• The team has not defined what the agent may do independently, what requires approval, or who owns the result.
• Without baseline metrics, the result cannot be compared with the previous way of working.

The team then keeps expanding instructions, restricting agent actions, and manually compensating for missing context. The pilot may work technically while the total time required to complete the process barely changes.

How Process Discovery should work

Process Discovery means reconstructing the actual workflow from work-system data and explanations from its participants. Its purpose is not merely to draw a diagram. It should confirm where work happens, which decisions are made, and what prevents the process from moving forward.

In Laplace, Context Audit can serve as the starting point for this analysis. It already helps find working-context problems in available Jira, Confluence, GitHub, and active calendar data: incomplete tasks, documentation gaps, weak links between objects, and unresolved decisions.

Context Audit is not a ready-made map of a business process and does not replace interviews with participants. A subsequent stage needs to connect the digital traces it finds with human understanding of the work.

• 1. Review Context Audit results to understand which sources are available and where context gaps were found.
• 2. Collect related tasks, documents, code changes, and calendar events.
• 3. Separate confirmed facts from hypotheses and unknown areas.
• 4. Conduct an adaptive interview with a process participant.
• 5. Compare the participant’s answers with digital traces.
• 6. Find delays, manual handoffs, and points where context is lost.
• 7. Build a map of the real workflow, including participants, sources, decisions, and exceptions.
• 8. Design a digital team for confirmed tasks within the process.
• 9. Prepare a limited pilot with a baseline, quality criteria, and points of human control.

Why the interview should be adaptive

A process participant does not need a long generic questionnaire. Questions should depend on the data, gaps, and contradictions already discovered.

If a task changed status several times, the interview should explore why it returned. If a meeting occurred but no decision appeared in the documentation, the agent should ask where it was recorded. If a pull request is not connected to a task, the important question is whether that is an error or an accepted team practice.

A participant’s account should not automatically become the complete process model. It needs to be compared with available tasks, documents, changes, and events. A discrepancy does not always mean the person is wrong: some work may happen outside the connected systems. That is a meaningful finding as well.

What Laplace is developing

Laplace is working on Process Discovery Agent, a new stage between Context Audit and the creation of a digital team.

We are developing an agent that will help connect work-system data with an adaptive interview of a process participant. Instead of asking everyone the same questions, it will ask follow-ups based on discovered gaps, unavailable sources, and contradictions.

We plan for Process Discovery Agent to help prepare the following outputs:

• A data-supported process model.
• A visual workflow map.
• A list of delays and manual handoffs.
• A list of unknown or inaccessible areas.
• AI opportunities within the process.
• A digital team design.
• A pilot plan with a baseline and success criteria.
• An assessment of confidence in the findings.

Example: developing a new product feature

Consider a product team that wants to release features faster. In the first discussion, participants identify coding speed as the main problem. A development assistant seems like the obvious solution.

Analysis of the actual workflow reveals a different picture:

• Tasks reach development without acceptance criteria.
• Decisions made in meetings do not always reach Confluence.
• Developers repeatedly clarify requirements with the product manager.
• Pull requests are not always linked to their source tasks.
• Documentation is updated after release or not updated at all.

In the proposed scenario, Process Discovery Agent will compare Jira tasks, Confluence pages, GitHub changes, and calendar events. It will then ask about the reasons tasks returned, where decisions were recorded, how code should link to tasks, and who owns documentation updates.

After comparing the data and answers, the team may discover that the main delay is not coding. Time is lost while context moves between task definition, implementation, and release preparation.

What a digital team design could include

For this process, a digital team design could include:

• An agent that reviews task definition quality.
• An agent that reconstructs context for a feature.
• A digital technical editor.
• A release preparation assistant.

A coding assistant may still be useful, but it is no longer treated as the only or the first solution.

The pilot runs with one team and one workflow type. Before it begins, the team records task cycle time, repeated clarification, returns, and missing links between tasks, documentation, and changes. The company then measures the effect of the digital team on a concrete process rather than the general ability of AI to generate text.

Why Process Discovery should show unknowns and confidence

A language model can produce a plausible explanation from incomplete data. For business-process investigation, that capability can be dangerous.

If part of the workflow is not visible in connected systems, an agent should not automatically invent the missing stages. Every significant conclusion should show:

• Which data supports the conclusion.
• What the process participant reported.
• Which sources were unavailable.
• Where data contradicts the explanation.
• How reliable the conclusion is.
• Which information needs manual verification.

For example, an agent may confirm that a task returned to active work three times without finding the reason. An interview can add the participant’s explanation, but it remains unverified if the decision was not recorded anywhere. The process problem may be precisely that decision reasons are never preserved.

Confidence should not become one opaque universal score. A team benefits more from understanding the evidence: which facts are confirmed, which conclusions rely on interviews, and where unknown areas remain.

How to choose the first workflow for AI

A suitable first process should be important enough for the result to matter and limited enough for the team to run a controlled pilot.

• The process repeats regularly.
• It has a concrete start and finish.
• It crosses several systems or participants.
• It contains visible manual handoffs.
• Its outcome can be verified.
• Consequential actions allow human approval.
• The current state can be recorded as a baseline.
• The process has an owner who wants to improve it.

The first pilot does not need to target the most expensive process. A workflow that makes it possible to test a hypothesis quickly, discover exceptions, and compare results with a baseline is often a better starting point.

Understand the work before building a digital team

The first step toward a digital team is not creating an agent. A company first needs to understand where the real work happens, why it slows down, and which part should actually be assigned to AI.

A procedure provides only the intended design. Work-system data shows individual facts. Interviews explain causes and exceptions. Only their combined analysis can reconstruct the process and identify a suitable automation scenario.

Frequently asked questions

What is Process Discovery?

Process Discovery is the reconstruction of a real business process from work-system data and explanations from its participants. The result should be an evidence-supported map of stages, decisions, participants, delays, and unknown areas.

How is Process Discovery different from Context Audit?

Context Audit helps find working-context problems in available sources. Process Discovery should go further by comparing digital traces with an adaptive interview and building a model of a specific workflow. Process Discovery Agent in Laplace is still in development.

Why are employee interviews not enough?

A participant may forget a rare step, omit a familiar manual action, or describe the process according to the formal procedure. Their answers need to be compared with tasks, documents, changes, and other digital traces.

How do you know whether a process is suitable for AI automation?

The process should repeat regularly, have a verifiable result and a clear owner, and allow human control. It is especially suitable when it includes meaningful search, data comparison, or manual transfer of context.

Do we need to document every company process first?

No. Start with one workflow, one team, or one task type. A limited pilot can test the hypothesis and collect evidence without an expensive investigation of the entire organization.