Foundry multi-agent workflows: passing values with evidence

Question

What may the next agent trust about a value it receives?

An employee requests an account “for sales, for the duration of the project.” One agent extracts a department, role, and expiry date; another prepares the application. Yet nobody has established whether “sales” names a department or describes the intended use. In this scenario, a neatly structured handoff can make an upstream inference look like a confirmed fact downstream.

The November 25 Foundry Agent Service multi-agent workflow announcement presents a public preview connecting steps through diagrams, YAML, variables, and structured output. Beyond role names and arrows, it provides components to define what passes forward and which conditions select a branch. This makes handoffs available for review beyond the implementer.

The concern here is passing meaning and evidence alongside values. Distinguish values extracted from a request, values checked against a directory, unresolved inferences, and the actual scope of an administrator’s approval. Making clear what a downstream step may trust is necessary design before adding more roles.

Announced capabilities

Review handoffs and branches in diagrams and YAML

Foundry’s announcement describes synchronized visual and YAML editing, with agent outputs stored in local variables for later steps. JSON Schema specifies output shape; Power Fx supports conditions and transformations. Each save creates an immutable version. Unlike an implicit conversational handoff, this provides a way to specify fields and branch conditions.

For an account request, successful department matching can take a different path from a result with multiple candidates. A reviewer of the diagram could check whether extraction leads straight to registration; a developer reading YAML could inspect the variables passed onward. These specific fields and paths are proposed here, not a supplied account-request process.

A definition describes possible paths, not evidence of execution. Even with an immutable workflow version, a directory update can change the match for the same request. Saving the handoff definition differs from recording the inputs and reference material that produced a particular value.

Limits of types

A valid string need not be a valid department

JSON Schema places conditions on data structure, including types and required fields. Representing a department as a string and roles as an array is useful: it can reduce failures where a downstream step receives an unexpected shape. A nonexistent department can still be a valid string, however, and the suitability of the listed roles for that employee needs a separate check.

Expiry dates require care too. The JSON Schema Draft 2020-12 validation specification distinguishes treating format as an annotation from checking conformity. Specifying a date format does not necessarily enable date validation. Foundry’s dialect and validation settings are not established by this announcement, so check the actual behavior.

Even a valid date need not match the project period stated in the request. Inventing a date merely to satisfy the output shape conceals uncertainty while passing a type check. Returning extracted fields separately from missing fields gives the next step information with which to stop correctly.

Scenario handoff

Move from extracted candidates to checked values

Consider three stages for the request. First, retain the requester’s identity and original text, then extract candidates for department, requested role, and expiry. If the text only says “for sales,” pass that description with an unresolved department rather than replacing it with an official department ID. Retain the relevant passage supporting the candidate where needed.

The matching stage uses an employee directory and role catalog. Check whether the requester has one matching department, the desired role is an allowed candidate, and the period complies with the rules. Multiple departments should lead to a clarification request; an unavailable directory should leave the result unverified and stop. Do not translate inability to check into either a nonexistent department or permission granted.

When preparing the application, distinguish the employee’s extracted request from fields confirmed through matching. Linking the request ID, directory and role-catalog versions, and missing information helps reviewers return to the evidence. These are proposed handoff fields, not a list of information Foundry saves automatically. Nor must every passage and piece of personal information be copied downstream: select what the check needs.

Approval and execution

An “approved” output is not an administrator’s authorization

Completing the checks does not necessarily establish permission to register the account. This scenario requires a record that the administrator authorized the requester, role, and period before creation. An agent-generated boolean or “approved” string alone does not provide evidence of that administrator’s decision.

If a three-month read-only approval is followed by a revised application for indefinite editing access, prevent registration under the same approval. Match who was permitted to receive which access, for how long, against the actual registration content. The application should check this match before changing access. This is the article’s human-approval scenario, not an argument that every operation requires a person’s confirmation.

A completed application also differs from a created account. If the external registration system reports failure or leaves its outcome unknown, the evidence is insufficient to display completion. Linking checks, the approval record, and the actual external result lets staff see which stage has been completed.

Adaptive planning comparison

Changing the search order does not turn an inference into a fact

Explicit handoffs do not require every step to be fixed. Magentic-One presents a research system whose orchestrator can replan. A task ledger contains facts, guesses, and the plan; a progress ledger helps determine the next agent and assignment. Specialists handle browsing, files, and code as the task develops.

For an account request, the order of searching for missing information may be allowed to change. An unsupported department or expiry must still not become confirmed simply to advance the plan. Magentic-One and Foundry are neither the same implementation nor a performance comparison. Comparing adaptive planning with explicit handoffs instead suggests that search flexibility and the scope of trusted values can be designed separately.

Agreement among multiple agents need not be independent verification. If one guesses a department, another copies it into the application, and a reviewer reads only that application, the same inference has been repeated three times. Giving the reviewer a route back to the directory or original request supplies a check that adding roles alone does not provide.

Investigating a run

Locate where an uncertain value became treated as confirmed

Foundry’s announcement describes tracing calls, inputs and outputs, variable assignments, and branches, plus built-in and custom evaluators. Initial-release observability focuses on individual Foundry agents inside a workflow. A displayed path therefore does not establish visibility into every state of external directories and registration systems.

Within that scope, inspect whether an unresolved department at extraction became an official department downstream. A directory match between those steps can explain the change; a model filling the gap cannot supply the missing evidence. Check not only whether the intended branch was taken, but also where its deciding value came from.

Trials should include ambiguous departments, missing expiry dates, lookup failures, and changes after approval. Alongside correct account creation, examine whether unverified values caused a stop and whether staff could return to the evidence. Comparisons with fixed procedures or a single agent, using the same input and directory, can show whether added delegation earns its place. Choosing an evaluator does not establish these criteria; define them from the request rules first.

Judgment

Judge what the next step receives before counting roles

Diagrams, variables, and structured output make multi-agent work easier to treat as a reviewable object. Yet the format used to pass information differs from the evidence for trusting it. Separating inference, matching, approval, and execution results in handoffs connects a visible workflow to actual business work.

The account scenario does not require separate models for extraction and application drafting. Directory matching and approval-content checks can also use defined procedures. If a team chooses multiple agents, it should explain whose judgment becomes clearer and which error becomes easier to detect. Without explainable evidence at each handoff, more roles may merely send the same uncertainty through a longer path.