Workflows¶

A workflow is a business process you write down once and Core then carries out for you. Think of an application that comes in: an agent summarises it, a tool looks the customer up in your CRM, a second agent drafts advice, and an administrator approves or rejects it. You draw those steps and the connections between them, and Core runs them, in the background and for as long as the process takes, even when it waits days for an answer.

How it works¶

flowchart TB
    start(["Start<br/>the application"]) --> summarise["Agent<br/>summarises"]
    summarise --> crm["Tool<br/>looks up the customer"]
    summarise --> advice["Agent<br/>drafts advice"]
    crm --> join["Join"]
    advice --> join
    join --> decision{"Decision<br/>an administrator"}
    decision -->|"approve"| done(["End"])
    decision -->|"reject"| rejected(["End"])

A workflow can have branches that run side by side, like the tool and the second agent above. A Join step brings them back together: when every branch is done, when the first is done, or when a number of them are done. A Condition picks a path based on what earlier steps produced.

What steps can do¶

• Work: an agent taking one turn, a single prompt to a model, or one call to a tool.
• Control: a condition, a join, reshaping data for the next step, and waiting until a point in time.
• People: a decision, which holds the run until there is an answer.
• Other workflows: a step that starts a run of another workflow, or one run per item of a list.

Every workflow begins at one start and finishes at an end. What the end receives is the run's output.

A run and its steps¶

A run goes in the background: you start it and your application does not have to keep waiting. Core carries out the steps in the order of the connections and records for each step what it received, what it produced, how often it was tried and whether it failed. When a step fails, the run fails, unless you gave the step a path on an error.

A run always acts as one key. Every step falls under that key's capabilities and policy as they stand at the moment the step runs, and the usage counts on that key. A workflow therefore reaches nothing the key could not call itself.

Every new run follows the newest version, unless it names a version. If you publish a new version while runs are going, those runs finish on the version they started with. A run may stay open for 30 days by default; after that it expires.

Decisions¶

A decision puts a question and names the outcomes to choose from, each with its own path. You choose who decides:

A decision by a person or a key can have a deadline, with what happens when nobody answers in time.

When you let an agent decide, Core guarantees that the answer is one of the outcomes, that the decision is marked as an agent's, and that you can read back the turn behind it. Core does not guarantee that the agent was not steered by the text it judges: if an application says "approve this", that can have an effect. So where the outcome matters, put a decision by a person after the agent's. What Core checks exactly is in An agent decides.

How a run starts¶

A run's page names which of these six it was under Started through.

Workflows inside workflows¶

A Workflow step starts a run of another workflow and waits until it is done; that run's output is the step's output. That way you build a large process from smaller ones you can also use on their own.

A Map step (map in the API) starts one run of another workflow for each item of a list, a number at a time, and returns the output of all those runs as a list. Use it when the same work has to happen for every line of an order or every document in a folder.

Such runs are ordinary runs, each with its own page and a link to the run they belong to. How deep runs may start each other and how many items a list may have is in the limits.

Sharing on the marketplace¶

A workflow can go into a publication, together with the agents, prompts and tools it uses. An organisation that installs the publication gets a copy it can start at once, with its own keys, triggers and schedules.

• Linked. The copy follows the publisher: a new version of the publication becomes a new version of the copy. The subscriber can read the steps but not change them, unless it detaches the copy where the publisher allows that.
• Sealed. The publisher hides the steps. The subscriber can start the workflow and sees for every run what the steps received and produced, because that is its own data.
• Withdrawn. When the publisher withdraws the publication, the terms decide what happens to the copy. If the subscriber may detach, the copy becomes its own. If the publication asks for an entitlement, the same happens as for a lapsed subscription, below. In the other cases the design disappears and runs that were still open fail. The runs themselves stay: what the workflow did at the subscriber remains the subscriber's.

When the subscription lapses, the workflow no longer starts and a run that is going fails at its next step. A run waiting for a decision or a wait step goes on if the subscription is restored in time. An organisation that installs a workflow must be allowed the capabilities workflows, runs and threads.

What is billed¶

• Every run is one use of the capability workflow_run, however it starts; the console calls it Workflow runs. That includes runs a step starts: a Map step over a hundred items is a hundred runs, beside the run the step is in.
• What the steps do is billed as always. An agent or prompt step counts as a turn with its tokens, a tool step as a call to that tool.
• Control and waiting cost nothing. A condition, a join, reshaping, waiting and a decision by a person or a key are not billed. A decision by an agent is: it is a turn of that agent.

The monthly cap of the key and the organisation is checked at every start and at every step that costs something. What your organisation used is shown in Usage in the console.

When to use a workflow¶

• A process has fixed steps in a fixed order, and you want exactly those steps to run every time.
• A process takes longer than one request: it waits for a person, a point in time or another system.
• You want to read back per step what happened, and catch a failed step.
• Work has to start on an event, a clock or a request from outside, without your own application running for it.

An agent with tools chooses its next step itself. A workflow chooses nothing itself: it follows the steps and connections you wrote down. For one question to an agent you need no workflow. An agent can start a workflow when it needs a fixed process.

Workflows are available when your operator has switched them on for the deployment and your organisation is allowed the capability workflows.

Read on¶