Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 10 · LESSON 10.10

Call Copilot Studio and Work IQ from FabrCore

Call Studio and Work IQ as remote agents with FabrCore handles.

Lesson 62 of 86 · FabrCore 2.0

Overview

Outbound remote agents let local orchestration address an external agent through a stable handle. Studio uses its direct-connect/Client SDK path; Work IQ reasoning uses its supported A2A contract. Remote conversation context belongs to the authorized principal and remote handle.

A local handle represents a remote capability

The outbound integration lets your assistant address an external Studio or Work IQ agent through a configured handle. The local orchestration still decides what question to send and how to combine the result. It does not turn the remote agent's implementation into a local plugin assembly or give you control over every remote model setting.

Remote context must retain the right owner

A remote conversation identifier belongs with the authorized principal and remote handle. Reusing it across accounts can mix context even if the local agents are isolated. Studio direct-connect and Work IQ's supported A2A path have distinct configuration requirements; use the profile/provider contract for the chosen service.

Call an external reasoning agent

  1. Enable the remote-agent service and configure the required connection/provider. Deploy a connectedAgents blueprint with exact provider and endpoint details.
  2. Send a normal FabrCore request to the remote handle. Persist task identifiers as they arrive and use status/resume/cancel for uncertain Work IQ requests.
  3. Treat reauthorization or rebinding as a remote-context reset. Verify provider-specific delegated scopes and live tenant compatibility.
Reusable blueprints · reference snippet 
{
  "name": "work-assistant",
  "connectedAgents": {
    "connections": {
      "work": { "ownerPrincipal": "$principal", "name": "workiq" }
    },
    "agents": [{
      "handle": "copilot",
      "agentType": "remote-agent",
      "args": {
        "provider": "work-iq",
        "connection": "work",
        "resource": "workiq",
        "endpoint": "https://workiq.svc.cloud.microsoft/a2a/",
        "timeZone": "America/Chicago"
      }
    }]
  }
}

Follow one request beyond the Host

  1. Configure one remote agent/profile in a test environment and ask a bounded question whose result is easy to identify. Inspect the local target handle and the external service's returned result.
  2. Send a follow-up under the same owner/context and verify continuity according to that provider's contract. Then use a different principal and confirm it does not inherit the earlier remote conversation.
  3. Make the remote service unavailable. The local assistant should identify the missing external result and avoid claiming that its own model completed the remote task.

The visible chain should connect local orchestration, protected connection, remote context and returned result. Each service remains independently responsible for its behavior.

If the result is different

An accepted request that returned no task ID may not be recoverable automatically. Do not repeat an uncertain mutation simply because the local request timed out.

Go deeper

Explore the related documentation.