How to move from discovery to drill-down using minimal, secure context handoffs.

The problem: agentic workflows can become monoliths

As agentic experiences mature, it’s tempting to build a single end-to-end app that does everything: interpret the request, query data, disambiguate, show details, and drive actions.

In practice, this quickly turns into a “mega-workflow” that’s difficult to evolve and govern—especially when different teams own different parts of the journey.

For example, consider a user searching for a customer account. A single agent might:
– Interpret the request
– Retrieve matching accounts
– Ask the user to disambiguate
– Load full account details
– Enable updates or downstream actions

Over time, this becomes tightly coupled. Even small changes—like refining search logic or updating the drill-down experience—can require coordinated updates across the entire flow.

This becomes even more complex in cross-domain scenarios—for example, moving from a customer search experience into an order investigation flow owned by another team.

A better approach: composability

A more scalable approach is composability: breaking the experience into focused agentic apps connected by a lightweight handoff.

The idea is simple: one app finds, another app resolves—connected by minimal shared context.

The pattern: a composable handoff using app context

At a high level:
1. App A (Customer Search and Identification) interprets the user’s prompt and runs the initial retrieval
2. When it’s time to go deeper, App A navigates the user to App B (Customer 360 fetching data from numerous sources using that Customer’s unique id as input)
3. App A passes a small app context parameter (Customer Unique Id) so App B can start immediately

The key design decision is what you pass: just enough context to continue, not the full response payload.

How it works (prototype approach)

In our prototype, App A created a small handoff context containing only a few essentials:
– Record identifier(s) (preferred over full payloads)
– Entity/attribute tags (i.e. PartyId, PartyNumber)

When the navigation mechanism expected a single string value, we packaged this as a small JSON object and encoded it for reliability.

App A then navigated to App B with that context attached.

On start-up, App B:
– Reads the incoming context
– Decodes/parses it
– Validates it
– Fetches authoritative data server-side
– Renders the drill-down experience immediately

Security and governance considerations

Within Fusion AI Studio, RBAC (Role-based access control) is already enforced, so the focus shifts from perimeter security to clear app boundaries and safe composition:

  • Enforce access at the point of use
    RBAC governs access, but each app remains responsible for applying its own domain-specific rules and constraints.
  • Context is a pointer, not data
    Pass only minimal identifiers and intent. Each app re-fetches authoritative data through its own domain logic.
  • No implicit trust between apps
    Treat incoming context as advisory. Validate structure and resolve it within the receiving app’s contract.
  • Keep ownership boundaries intact
    Avoid passing full payloads or embedding business logic in the handoff—this prevents tight coupling across teams.

Wrap-up

Composable agentic apps connected through lightweight context handoffs help avoid monolithic workflows, improve reuse, and make ownership boundaries clearer.

The key to making this work is discipline: keep context minimal, validate it rigorously, and always resolve data within the receiving app’s own domain logic