Automation of workflow is a five-step pipeline. Here is the file that runs it.

Why the standard explainer is the easy half

Pull up the top results for this topic and read them side by side. Atlassian, Zapier, Workato, Hyland, Outsystems, Zoho, TechTarget, Creatio. Every one of them converges on the same model. A workflow is a sequence of steps. Automation is what happens when something fires that sequence without a human present. The bridge between the two is a trigger. They differ on which connectors they list, which industry they pitch, and how aggressively they badge themselves as AI. They agree on the trigger-condition-action diagram.

The diagram is correct. It describes the runtime. It does not describe how the workflow got there. The first step in every one of those guides reads roughly “define the workflow you want to automate,” which is the equivalent of a recipe book that starts with “first, decide what you are cooking.” The interesting work, the work a real ops team has to actually do, is taking a person’s actual day on a Windows desktop and turning it into a structured object that can be scheduled, monitored, and audited.

That conversion is the act referenced by the phrase “automation of workflow.” In the Mediar monorepo it is one Python file, one decorated function, and five sequential POST requests against five Next.js API routes. The rest of this guide opens that file and walks each step.

The orchestrator: one function, three hours, five endpoints

The whole pipeline is a single Modal function. It is a sales-led pilot tool, not a fire-and-forget batch job, which is why it is decorated with keep_warm=1 (one container kept hot to avoid cold-start pause) and timeout=10800 (three hours, in seconds, as the outer wall on the entire run).

# modal_apps/workflow_synthesis_orchestrator.py
@app.function(
    secrets=[modal.Secret.from_name("supabase-secret")],
    timeout=10800,  # 3 hours = 10,800 seconds
    keep_warm=1
)
def orchestrate_workflow_synthesis(
    user_id: str,
    model: str,
    start_date: str,
    end_date: str,
    user_instructions: str = ""
) -> Dict[str, Any]:
    """
    Run all 5 workflow synthesis steps by calling Vercel
    endpoints sequentially.
    """

Inside the function body, five sequential requests.post calls hit the production Vercel deployment at app.mediar.ai. Each one carries its own thirty-minute HTTP timeout. The pipeline is a straight line, not a DAG, and the order is fixed.

The five labels on the diagram correspond to five endpoint folders under apps/web/src/app/api/: initiate-workflow-analysis, refine-workflow-list, define-workflow-boundaries, synthesize-workflow, and analyze-raw-timeline-events. The remainder of this guide walks them in that order.

Step 1 of 5

Initiate. Look at the raw recording and produce candidate workflow names.

The first endpoint, /api/initiate-workflow-analysis, takes a user id, a model name, a start date, and an end date. It pulls the user’s low-level event analyses from Supabase for that window, runs them through a Vertex AI prompt called PROMPT_SYNTHESIZE_CONTEXT, and streams back a Server-Sent Events response with two pieces of state: a workflowContext object (essentially a high-level read on what the user does, what industry, what tools they live in) and a workflowNames list (a first-pass guess at the recurring workflows visible in the recording).

The output is intentionally rough. It is the model’s first guess at the universe of automatable workflows, with no deduplication and no boundary information. A typical first-pass list at this stage might contain ten workflow names where four turn out to be the same thing called three different ways and two turn out to be one-off events that happened to fire during the recording window. That is fine. The next step exists precisely to prune the list.

The streaming response shape matters here. Step one is the only one of the five (along with step five) that uses SSE rather than a single JSON response. The orchestrator parses the SSE chunks with a small parse_sse_response helper, scanning for lines that start with data: and accumulating the final state into one dict. The reason for the streaming format is that the synthesis prompt at this step can run for several minutes, and the desktop UI uses the intermediate progress events to keep the user informed instead of showing a spinner that looks frozen.

Step 2 of 5

Refine. Take the rough list and prune to the workflows that are actually recurring.

The second endpoint, /api/refine-workflow-list, takes the workflowContext and draft_workflow_names from step one and runs them against PROMPT_REFINE_WORKFLOWS_AND_CONTEXT. The model is told its job is to dedupe the list, throw out one-shot events that are not real workflows, merge synonyms, and return a refined_workflow_names list that has been cleaned of the first-pass noise.

This is the step that most explainers gloss as “decide what to automate.” In source it is forty lines of TypeScript plus a Vertex call with a structured-output schema named WORKFLOW_REFINEMENT_SCHEMA. The same 1,000-row analysis window from step one is re-fetched (the Supabase query lives in the route file, not in shared state) so the refinement model is looking at the same evidence the initiation model was. The per-step timeout is thirty minutes, the same as every other step. In practice the refinement call returns in under five minutes on a representative recording, but the cap exists so a stuck Vertex response cannot block the rest of the pipeline.

The output of step two is still just a list of names. No triggers. No actions. The next step is where the workflows start becoming candidates for automation rather than labels on a list.

Step 3 of 5

Boundaries. Find the trigger and the terminator for each workflow.

Step three is the moment a workflow becomes automatable. The third endpoint, /api/define-workflow-boundaries, takes the refined names and runs them against WORKFLOW_BOUNDARIES_PROMPT, with the structured-output schema forcing every workflow in the response to carry three required fields. The schema is short and worth printing in full.

// apps/web/src/lib/prompts.ts (lines 472-489)
// The schema that turns a workflow name into something automatable.
export const WORKFLOW_BOUNDARIES_SCHEMA = {
  type: "object",
  properties: {
    workflows: {
      type: "array",
      items: {
        type: "object",
        properties: {
          workflow_name: { type: "string" },
          trigger:       { type: "string" },
          terminator:    { type: "string" }
        },
        required: ["workflow_name", "trigger", "terminator"]
      }
    }
  },
  required: ["workflows"]
};

Three required fields. workflow_name carries forward from step two unchanged. The two new fields are where the value is. trigger is a sentence describing the concrete event that starts the workflow. terminator is the concrete event that ends it. The example in the docstring of WORKFLOW_BOUNDARIES_PROMPT uses an invoice workflow:

trigger: “The workflow begins when an email with ‘invoice’ in the subject arrives from a known vendor.”
terminator: “The workflow ends when the payment status for the corresponding invoice is marked as ‘Scheduled’ in the accounting software.”

Read those two strings carefully. They are written in business language, not in code. They name a concrete observable event on one side and a concrete observable end-state on the other. With the trigger string in hand, a downstream system can answer “is this workflow starting right now?” against any arriving event. With the terminator string, it can answer “did this workflow finish?” The boundary pair is what every other guide hand-waves when it tells you to “define the workflow.” In Mediar’s pipeline the pair is named in a JSON schema, the schema is enforced by structured output, and the result is checked into the database.

One detail worth pulling out: step three accepts a userInstructions string in its context payload. If the user typed something like “treat anything in Outlook as out-of-scope” into the desktop UI, that string flows into the prompt at this step (and at step four), and the model uses it to override its default reading of the boundaries. The override is by passing notes through, not by adding a configuration flag, which is the Mediar shape: prompt engineering as a first-class user-facing surface.

Step 4 of 5

Synthesize. Turn the boundaries into a hierarchical, runnable workflow object.

The fourth endpoint, /api/synthesize-workflow, is the largest of the five route files (around 640 lines). It takes the workflows-with-boundaries from step three, the same 1,000-row analysis window, up to 500 transcript rows from agent_live_transcriptions, the user’s high-level workflowContext, and any userInstructions, and runs them against WORKFLOW_SYNTHESIS_PROMPT. The output schema is large enough that printing it would fill the rest of this page; the interesting part is the rules the model is held to.

// apps/web/src/lib/prompts.ts, WORKFLOW_SYNTHESIS_PROMPT
// (excerpt of the rules the model is held to at step 4)
//
// 5. Synthesize Hierarchical Steps: Each workflow breaks into
//    high-level steps. Each step breaks into granular substeps.
// 6. Detail Each Sub-step: For every sub-step you must define
//    its inputs (what triggers it), outputs (what results from
//    it), and business_logic (the rules governing it).
// 7. Define Workflow Variations (Types): Identify and define
//    different paths the workflow can take. Describe the
//    conditions for each type.
// 8. Identify Concrete Examples (Instances): Extract specific,
//    concrete examples of the workflow being executed.
// 11. Do Not Hallucinate: Base all synthesized information
//     directly on the provided context, event data, and
//     conversations.

Read the numbers. Each workflow becomes a tree: high-level steps, sub-steps under each step. Every sub-step gets three required string fields, inputs (what triggers it), outputs (what results from it), and business_logic (the rules governing it). The branching paths the workflow can take become workflow_types, with a name, a description, and a conditions object. The concrete past executions of the workflow become workflow_instances, with a descriptive name and a structured instance_data dict.

The reason step three exists separately is exactly so the model can spend its full reasoning budget on synthesis here. The step three call has one job: fill in two strings per workflow. The step four call has the much larger job of generating a tree with ten or twenty leaves, each carrying three string fields. Splitting them lets each call use a focused prompt, a small schema, and a constrained context window. Trying to do both in one call produces structured outputs that mis-fill or skip the deeper fields, which is a failure mode anyone who has done structured-output prompt engineering will recognize.

The synthesized workflow lands as JSON on the response, gets written back to the orchestrator’s results dict understep_results.step4, and is also persisted to Supabase by the route file before the response returns. After step four, the workflow exists as a structured object that the desktop UI can render, the Rust executor can run, and a human reviewer can read.

Step 5 of 5

Timeline. Map the synthesized workflow back to the raw evidence.

The final endpoint, /api/analyze-raw-timeline-events, is the part most explainers do not have an analogue for. It takes the synthesized workflows and walks the original chronological event log, labeling each segment with which workflow it belongs to. The output is a workflow_mappings list: a sequence of (workflow_name, time_range, supporting_event_ids) triples that lets the desktop UI overlay the synthesized workflows onto the user’s actual recorded day.

The audit value is the point. After step four, the workflow is a definition that claims to describe what the user did. After step five, every claim in that definition can be traced back to a row in low_level_workflow_analyses, with a timestamp and an analysis id. A reviewer can open any sub-step in the synthesized object, click through to the supporting events, and verify that the workflow as written matches the workflow as observed.

This is the step that turns the pipeline from “impressive AI demo” into “something the internal compliance team can sign off on.” In a regulated industry (banking core systems on Jack Henry, Fiserv, FIS; healthcare on Epic or Cerner; insurance claims) the audit trail is not optional. The pipeline ships the audit trail as step five rather than as a bolt-on, which is the difference between a product that has thought about the deployment surface and one that has not.

The bounds the pipeline enforces on itself

Six numbers, each named in source, each a policy decision rather than a tunable knob. They are the right shorthand to take into a buying conversation about how a vendor turns observation into an executable workflow.

The three-hour wall, in one number

The outermost bound is timeout=10800 on the Modal function decorator. In seconds. That is:

What this means if you are evaluating tools

The reason it is worth opening one orchestrator file rather than reading another high-level explainer is that the five steps and the six bounds tell you, more honestly than any feature list, what the vendor is actually doing when they say they will “automate your workflow.” If the vendor cannot name the equivalent of step three (the moment a workflow becomes automatable, the moment a trigger and a terminator string are named), then they are selling the runtime diagram, not the conversion that produces something for the runtime to run.

UiPath has Task Mining. Microsoft has Process Insights. Celonis has a process discovery suite. Each has analogues of these five steps. The Mediar version is open about its shape because the orchestrator is one Python file you can read at modal_apps/workflow_synthesis_orchestrator.py, every API route is one route file you can read under apps/web/src/app/api, and every prompt is one named export under apps/web/src/lib/prompts.ts. The runtime executor that consumes the output is the Rust Terminator project on github.com/mediar-ai/terminator, published under MIT.

That openness is the difference between evaluating the pipeline and trusting a vendor slide that summarizes it. Five steps, three required fields at step three, one tree per workflow at step four, an audit trail at step five, six bounds. The shape of how a workflow gets automated, in less than a screen of numbers.

Questions a buyer eventually asks