Skip to main content
You can ask Sofie to build an Orchestration from chat. This is useful when you know the workflow outcome but do not want to start by manually placing agents, tasks, inputs, tools, and review steps. If you are still deciding whether the workflow should become an Orchestration, start with Use Orchestrations intelligently.

​
Start with a clear workflow request

Tell Sofie the repeatable job you want to create. Include the business context, expected inputs, expected output, and review points. Use this structure: 
Build an Orchestration for:

Workflow:
Users:
Required inputs:
Optional inputs:
Source context:
Output:
Human review points:
What Sofie should not assume:
Example: 
Build an Orchestration for CAPA effectiveness checks.

Users: QA owners and process SMEs.
Required inputs: CAPA plan, effectiveness criteria, target metrics, evidence files, observation window, Workspace.
Optional inputs: prior CAPAs and related deviations.
Source context: Use Workspace files and any attached CoSheets.
Output: A CoDraft report with evidence table, metric assessment, unresolved questions, and a draft conclusion.
Human review points: Before drawing the conclusion and before creating the final CoDraft.
What Sofie should not assume: Do not infer missing acceptance criteria or effectiveness thresholds.
If the workflow involves regulated or quality decisions, ask Sofie to include assumptions, source gaps, and human review points in the Orchestration design.

​
Add source context

Before asking Sofie to build, add the context it should understand. You can attach or add:
  • A Workspace that contains related files.
  • A CoDraft template or example deliverable.
  • A CoSheet with data columns and sample rows.
  • A CoMeeting transcript that describes how the process works.
  • Files such as SOPs, protocols, reports, or spreadsheets.
  • A Saved prompt that contains your preferred workflow language.
When the Orchestration should always ask for a source later, describe that as an input instead of attaching only today’s example.

​
Ask Sofie to propose the design first

For complex workflows, ask for a design review before creation. 
Before creating the Orchestration, propose the inputs, agents, tasks, tools, output format, and human review points. Return a table and ask me questions where the workflow is ambiguous.
Review the proposal for:
  • Missing required inputs.
  • Inputs that should be optional.
  • Too many agents.
  • Tasks that depend on missing sources.
  • Review points that happen too late.
  • Outputs that are too vague to review.

​
Create the Orchestration from chat

After you approve the design, ask Sofie to create it. 
Create this Orchestration. Keep it as a draft. Use the inputs and review points we agreed on. After creating it, give me a checklist for the first test run.
Sofie may ask follow-up questions before creating the Orchestration. Answer them in the same chat so the creation request and decisions stay together.
If Sofie cannot complete the creation from chat in your environment, use the proposed design as the blueprint in /orchestrate/build-orchestrations.

​
Open the result in Orchestrate

After Sofie creates or prepares the Orchestration, open it in Orchestrate. Check:
  • Name and description.
  • Input names, labels, descriptions, and required settings.
  • Agent role, goal, and backstory.
  • Task descriptions and expected outputs.
  • Tool choices.
  • Human review settings.
  • Output mode and destination.
  • Draft or published status.
Use the Orchestration editor for detailed control. Use chat for iterative design help.

​
Test from chat

You can also run an Orchestration from chat. Example: 
Run the CAPA effectiveness check Orchestration. Use the CAPA plan in this Workspace, the attached metrics CoSheet, and the observation window from January 1, 2026 through March 31, 2026. Ask me before drafting the final conclusion.
When an Orchestration needs required inputs, Sofie can ask for them before the run starts.

​
Refine from the test output

After the first run, ask Sofie to inspect the result and suggest changes to the Orchestration. 
Review this Orchestration result. Identify where the workflow asked for the wrong input, skipped a source check, produced vague output, or needed human review earlier. Suggest edits to the Orchestration design.
Then edit the Orchestration directly or ask Sofie to help revise it. When the workflow is repeatable enough to reuse, add Orchestration tests before publishing. See Test Orchestrations for manual tests, saved-run baselines, validation methods, run history, drift, parallel execution checks, and Memory checks.

​
Prompt examples

Build an Orchestration for deviation investigation report drafting. Required inputs should include deviation description, immediate actions, related batch or equipment files, evidence sources, SME interview notes, and Workspace. The output should be a CoDraft with issue description, timeline, evidence table, potential root causes, missing evidence, and open questions. Add human review before root cause conclusion and before final document creation.

Build an Orchestration for equipment URS drafting. Required inputs should include equipment type, process use, product or process constraints, user needs, relevant standards or procedures, and example URS template. Output should fill a CoDraft template with requirements, rationale, verification method, and open questions. Do not invent requirements that are not supported by the sources.

Build an Orchestration for batch record review. Inputs should include the batch record file, product, batch number, review focus, and Workspace. Output should be a table of findings with section, observation, possible impact, source reference, owner question, and disposition status. Add human review before any disposition recommendation.

​
What to specify for better Orchestrations

SpecifyWhy it matters
InputsUsers need to know what to provide before running the workflow.
Source prioritySofie needs to know which sources outweigh others when they conflict.
Output shapeA table, CoDraft, structured result, or template is easier to review than a loose answer.
Review pointsHuman review should happen before conclusions, saves, or final outputs.
Non-assumptionsTell Sofie which facts, limits, criteria, or decisions it must not infer.
DestinationDecide whether output stays in chat, becomes a CoDraft, or saves to a Workspace.
For manual editing details, see Build and edit an Orchestration.