> For the complete documentation index, see [llms.txt](https://kb.theloops.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.theloops.io/agentstudio/resource-library/explainers/digital-crew-coordinated-digital-workers-for-end-to-end-processes.md). # Digital Crew: Coordinated Digital Workers for End-to-End Processes ### What is a Digital Crew? A Digital Crew is a coordinated team of Digital Workers that owns an entire business process, from first touch to final step, so nothing falls through the cracks between individually automated tasks. Where a single Digital Worker automates one focused role, a Digital Crew brings several Digital Workers together around a shared process, each handling its part and passing the work on to the next automatically. Digital Crew is the second step in the IFS Loops platform's path to enterprise autonomy:


Stage	What it is	Business Value	Status
Digital Workers	Discrete agents automating individual micro-processes. One Digital Worker, one focused role, such as dispatching, invoicing, or knowledge retrieval.	Makes one part of a process faster, more consistent, and easier to govern.	Available
Digital Crew	A coordinated team of Digital Workers connected through triggers, handoffs, and shared process context that owns an entire process end to end.	Moves work across multiple steps without relying on manual routing or informal ownership.	Available

### **Why it Matters** Many real business processes need more than one focused agent to complete. Historically, that has meant stitching several Digital Workers together by hand, or relying on a single Digital Worker to cover one step and leaving the rest of the process to manual work. Handoffs between steps are where things go wrong: a requirement is understood differently by each system involved, a gap is only discovered partway through, or a case sits waiting because no single owner is watching the whole process. Digital Crew addresses this directly. Instead of a chain of point automations, a Digital Crew is designed around the process itself. Each Digital Worker in the crew has a clear, bounded role, and its output automatically moves the process on to the next Digital Worker. The crew, not any single Digital Worker, is accountable for the outcome, which means: * Fewer things fall through the cracks between steps that used to be handled by different people or systems. * Work that would previously stall waiting for a person to notice a handoff moves on automatically to the next Digital Worker in the crew. * Process ownership is clearer, because the crew is defined by what it is responsible for delivering. * Where no Digital Worker in the crew can complete a step, for example when no qualified resource is available, the crew brings a human in the loop rather than guessing or producing an incomplete result. * You get a clear view of how work is progressing across the whole process, not just one step of it. ### **How a Digital Crew Works** * **Bounded roles:** each Digital Worker in a crew has a clearly defined scope, what it owns and what it produces, so responsibility for each part of the process is unambiguous. * **Shared understanding:** every Digital Worker in a crew draws on the same underlying knowledge of the business, its Ontology (a shared business map described later in this article). The crew reasons about customers, orders, assets, and resources consistently, rather than each Digital Worker holding its own version of the truth. * **Trigger-based handoff:** every Digital Worker starts from a trigger: a schedule, an inbound email, a system event, or the output of another Digital Worker. In a Digital Crew, those same triggers connect the Digital Workers together. One Digital Worker's output can act as the trigger that automatically starts the next one's process, so the crew keeps moving without a person needing to notice a handoff and route it manually. * **Escalation, not guessing:** if a crew reaches a point it cannot resolve on its own, for example when no valid option meets the requirement, it flags this to the right person instead of proceeding with an answer that does not meet the bar. A Digital Worker later in a crew can also keep its own independent trigger, such as reacting to an incoming email, alongside picking up work passed on from earlier in the crew. ### Example: Procure-to-Pay Crew The screenshot below shows a live Digital Crew configured for an agentic procure-to-pay (P2P) process, where Digital Workers are responsible for most of the process from sourcing through to supplier invoicing. **Each card in the crew shows what that worker runs on, what it does, and where its output goes next:** * A schedule (CRON) starts the crew by triggering the Sourcing Manager, which turns a purchase requisition into a request for quotation. * The Sourcing Manager's output is the trigger for the Material Replenisher DW, which is itself the trigger for the Inventory Replenisher Orchestrator, and so on — each card runs on “Handoff from the previous worker.” * Further along the same crew, the Supplier Order Mgr and Supplier Invoicing Manager also react to their own inbound Outlook events — such as a supplier's PO confirmation or invoice email — while still passing their output on to the next worker in the crew. * The last worker's output becomes the crew's output. The Crew Builder view of a live procure-to-pay (P2P) Digital Crew, showing the trigger, each worker's role, and the handoff to the next worker

The Crew Builder view of a live procure-to-pay (P2P) Digital Crew, showing the trigger, each worker's role, and the handoff to the next worker

A live crew like this also reports on itself at a glance: how many workers make up the crew, how many cases are currently in flight, how many need a human to step in, and how many were cleared that day — giving full visibility into the health of the process, not just one step of it.


Process characteristic	How Digital Crew helps
Multiple handoffs across sourcing, supply, and invoicing	Automates transitions between Digital Workers so cases continue without manual routing.
Mixed trigger types	Supports both worker-to-worker handoffs and independent inbound events within the same crew.
Operational visibility	Shows crew-level activity such as work in progress, escalations, and completed outcomes.

### Example: Field Service crew assembly Digital Crew applies just as directly to Field Service Management. Consider crew assembly for jobs that need more than one engineer. This was previously a manual task, where a planner had to hold in their head which certifications a job requires, which combination of engineers covers them, who is available, who is close enough, and whether the SLA still holds once travel time is included. In a Digital Crew, this becomes a chain of triggered steps: 1. A planning Digital Worker identifies that a job requires more than one engineer and defines the certifications and skills needed. Completing this step triggers the next Digital Worker in the crew. 2. A crew-assembly Digital Worker searches the available field workforce, evaluating certifications, proximity, capacity, and SLA constraints together, not availability alone, and assembles the best-matched crew. 3. Confirming a valid crew is itself the trigger for the next step. It automatically starts the dispatch Digital Worker's process, so scheduling begins without anyone needing to route the work. 4. Where no valid crew exists, the crew-assembly Digital Worker's output instead triggers an escalation to the planning team, rather than triggering dispatch with an incomplete team that will fail on site. ### Digital Crew domains


Domain	Crew workflows	How Digital Crew helps
Field Service Management	First Time Fix, Proactive Maintenance, SLA Priority, Repeat Visit Prevention, Revenue Recovery	Coordinates planning, crew assembly, dispatch, and exception handling.
Procurement	Source-to-settle process ownership across sourcing, ordering, and supplier management	Connects procurement steps into one governed process instead of separate automations.
Enterprise Asset Management	End-to-end asset upkeep, from planning through completion and close-out	Maintains continuity across planning, execution, completion, and close-out steps.
Finance	Faster Close, Cash Visibility, Touchless Transactions	Links finance process steps into more consistent, lower-touch workflows.

### Applications and Ontology Applications and ontology are the supporting concepts that make Digital Crew practical to configure and govern. Both are available as tabs alongside the Crew Builder. #### Applications Applications are the executable configuration behind a Digital Worker or crew. They connect the business concept to the app-building and workbench flows that you interact with. When a Digital Worker in the library shows that an application is still needed, the application must be created before the crew can rely on that Digital Worker. #### Ontology Ontology is the business map behind Digital Workers and Digital Crew. It defines the concepts the crew works with, the responsibilities each Digital Worker owns, and the relationships that guide handoffs between Digital Workers. Ontology makes the crew understandable and governable. It helps your team check whether the process uses consistent terminology, models the right business responsibilities, and connects Digital Workers through meaningful business relationships instead of only technical integrations. The Ontology view shows how these concepts are organized, including responsibilities, relationships, and governance context.

*The Ontology view, showing business concepts and the relationships between them.*

### Building a Crew, Step by Step Digital Crew builds directly on your existing Digital Workers, so it runs on the same platform with no separate setup and no new automation model to learn. Crews are assembled in the Crew Builder inside Agent Studio. A new crew starts empty, with a single prompt: add a Digital Worker from the library, then drop it onto the canvas. From there, a crew is built up one Digital Worker at a time.

*A new crew starts empty. Adding a Digital Worker from the library and dropping it onto the canvas is the only step needed to begin.*

{% stepper %} {% step %} Add a Digital Worker from the library. {% endstep %} {% step %} Place it into the crew flow. {% endstep %} {% step %} Define its **Runs on**, **Does**, and **Outputs**. {% endstep %} {% step %} Connect Digital Workers through handoffs or event triggers. {% endstep %} {% step %} Repeat until the process is represented end to end. {% endstep %} {% step %} Monitor the crew to track work in progress, exceptions, and outcomes. {% endstep %} {% endstepper %} ### Describing each Digital Worker Each Digital Worker added to the crew is defined in plain language, in a short prompt with three fields. This is the same Runs on, Does, and Outputs information shown on the Digital Worker's card once it is saved. Describing it here is what wires the Digital Worker into the crew.

*Describing a Digital Worker's place in the crew: what it runs on (its trigger), what it does, and what it outputs.*

* **Runs on:** the trigger for this Digital Worker: a schedule, an inbound event such as a supplier email, or the handoff from the Digital Worker before it in the crew. * **Does:** a plain-language description of the work this step performs. * **Outputs:** what this step produces, which becomes available to trigger the next Digital Worker in the crew. This structure keeps the crew easy for business users to understand while keeping the process precise enough to configure and govern. ### Choosing Digital Workers from the library A crew grows the same way it starts: by adding further Digital Workers from the library. Each library entry shows what it automates and its automation rate before it is added. Selecting a Digital Worker shows more detail, including its purpose, autonomy level, confidence threshold, skills, connected systems, and application status.

*Adding a Digital Worker to a crew from the library. Each entry shows its automation rate.*

Use this detail to decide whether a Digital Worker is the right fit for a responsibility in the process, and whether it is ready to use or needs an application created before the crew can rely on it. **Add to crew** appends the Digital Worker to the end of the sequence. Once described, it takes its place in the crew, wired in and ready to pick up the handoff from the Digital Worker before it.

*Library detail for the Sourcing Manager Digital Worker, including autonomy level, confidence threshold, skills, and application status.*

Add a new Digital Worker when the flow needs a distinct responsibility, such as checking eligibility, enriching case information, updating a system, waiting for an external response, or handling an exception. {% hint style="info" %} **Best practice:** keep each Digital Worker focused on one bounded responsibility. The crew can cover a broad process, but each Digital Worker should stay precise. {% endhint %}