Skip to main content
Knowledge bases do not share raw retrieval context. To use expertise from another KB, let an agent delegate to an agent on that KB. The caller receives the specialist’s final answer—not its documents, retrieved passages, prompt, or tool history.

The boundary

Caller KB                                  Specialist KB
Private corpus                             Private corpus
    │                                           │
Caller agent ── ask specialist ──► Specialist agent
    ◄──────── final answer only ────────────────┘
This keeps retrieval isolated while allowing agents in the same tenant to compose specialized knowledge.

What is and is not shared

Shared with the callerStays with the specialist
Final answerRaw documents and retrieved chunks
Success or graceful failure messageSystem prompt and internal tool history
Delegated-agent usage attributionDatabase connections and private configuration
Delegation is not a way to merge two corpora. If one answer must retrieve passages from both document sets directly, place those documents in the same knowledge base instead.

Three delegation patterns

Attach a specialist agent as callable. Both agents already use the same corpus, so no cross-KB sharing decision is involved.
The target KB must allow inbound delegation. Cross-KB delegation stays within one tenant and returns only the target agent’s final answer.
Register an external Agent-to-Agent endpoint on a KB, then expose it as a delegate. External registration is outbound configuration and is independent of the KB’s inbound-sharing setting.

Configure it in the dashboard

1

Create the specialist

Build and test an agent on the target knowledge base. Give it a narrow goal so its answer is useful to callers.
2

Allow inbound delegation

On the target KB, keep inbound delegation enabled. Turn it off for KBs that should not answer other agents.
3

Attach the specialist

Open the calling agent and add the specialist under Callable agents, then deploy the updated calling-agent configuration.
4

Test the boundary

Run the caller with a question that requires the specialist. Confirm the response uses the delegated answer without exposing the target corpus.
Delegation is single-hop: the specialist returns to its caller rather than delegating onward. This keeps execution bounded and predictable.

Build it with the API

Enable inbound delegation on the specialist’s KB:
curl -X PATCH "$AUTOSAGE_URL/knowledge-bases/SPECIALIST_KB_ID" \
  -H "Authorization: Bearer $AUTOSAGE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_sharing": {
      "inbound_delegation_enabled": true
    }
  }'
Create a caller with the specialist attached:
curl -X POST "$AUTOSAGE_URL/agents" \
  -H "Authorization: Bearer $AUTOSAGE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "tenant_id": "TENANT_ID",
    "name": "Customer briefing agent",
    "goal": "Prepare a complete customer briefing.",
    "instructions": "Ask the policy specialist when the request depends on policy details.",
    "model_id": "MODEL_ID",
    "selected_knowledge_base_id": "CALLER_KB_ID",
    "callable_agents": [
      { "agent_id": "SPECIALIST_AGENT_ID" }
    ]
  }'
Run the caller normally. The runtime makes the specialist available through its delegation tool.

Register an external A2A agent

curl -X POST "$AUTOSAGE_URL/knowledge-bases/KB_ID/a2a-agents" \
  -H "Authorization: Bearer $AUTOSAGE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "External policy specialist",
    "description": "Answers policy questions from the partner system.",
    "cardUrl": "https://partner.example.com/.well-known/agent-card.json"
  }'

Continue the learning path

Agent delegation

Understand callable-agent behavior and graceful failures.

Agent sharing settings

Control which KBs accept inbound calls.