Start in Capabilities > Systems. Connect every MCP system your agent should be allowed to use. For presets, fill required env values (database URL, API key, or token), then click Connect. For custom systems, verify the launch command and env keys first, then connect.

Do this in order:
- Connect one system at a time.
- Use "Inspect Tools" to confirm tool schemas loaded.
- Fix env warnings before moving on.

Success criteria:
- Each required system shows Connected.
- Tool count is non-zero for each connected system.
- No missing config errors on system cards.

Treat tools as your agent's permissions surface. Keep only the minimum set needed for the job. Remove duplicate tools across systems unless there is a clear fallback reason.

What to check for each tool:
- Clear name and description.
- Required arguments make sense.
- Side-effect level (read vs write).
- Return shape is usable by downstream steps.

Success criteria:
- Only task-relevant tools remain enabled.
- No ambiguous duplicate tools left active.

In Capabilities > Tool Rules, set when each tool should be selected and how inputs should be constrained. This is where you turn raw MCP schemas into safe, predictable runtime behavior.

Minimum policy baseline per tool:
- Selection intent keywords (when this tool should be used).
- Allowed and required inputs.
- Bounds for limits/pagination/date ranges.
- Required source(s) where applicable.

Success criteria:
- High-risk tools have strict input guardrails.
- Tool selection is deterministic for common intents.

Create an agent with a single clear job. Keep the system prompt short, explicit, and operational. Assign only approved tools from the previous step.

Prompt pattern that works well:
- Role: what this agent does.
- Constraints: what it must not do.
- Output style: how responses should be structured.

Success criteria:
- Agent prompt is concise and testable.
- Tool list matches role boundaries.

If your use case needs documentation recall, add a Knowledge dataset and link it to the agent. Keep collections scoped by domain (support, product docs, policy, etc).

Best practice:
- Split large mixed docs into focused collections.
- Remove stale files before production rollout.
- Re-index after major content updates.

Success criteria:
- Collection status is ready/indexed.
- Agent is attached to the intended collection(s).

Use Capabilities > Orchestration when tasks need multi-step tool workflows. Start with a small chain: collect input, call tool(s), return structured context.

Chain design baseline:
- One intent per chain.
- Clear step labels and output keys.
- Explicit tool order for dependencies.

Success criteria:
- Chain dry run returns expected intermediate outputs.
- No hidden dependency on undeclared tools.

Use Runs > Playground to validate real behavior with user-like prompts. Test simple, normal, and edge-case requests before going live.

Recommended test set:
- Happy path request.
- Missing input request.
- Ambiguous request that should trigger clarification.

Success criteria:
- Tool calls match intent.
- Outputs are stable and explainable.

When behavior is wrong, use traces to identify where it broke: selection, input args, source gaps, or tool failures. Always debug from the first unexpected step in the timeline.

Triage order:
- Source Availability (missing required systems).
- Tool arguments and filters.
- Identity Coverage (mapped vs unmapped entities).
- Tool error payloads and timeout signals.

Use Identity Graph to reconcile cross-system IDs into canonical entities. This unlocks accurate multi-source answers instead of fragmented results.

Operating model:
- Resolve high-volume entities first.
- Keep unresolved queue near zero.
- Recheck identity coverage after each mapping batch.

Before rollout, make sure the full stack is auditable and predictable.

Release checklist:
- Systems connected and healthy.
- Tool Rules configured for all critical tools.
- Agent prompt and tool set versioned.
- Chains tested on realistic payloads.
- Trace review completed for failure scenarios.

Week-1 operations:
- Monitor tool error rate and timeout trend.
- Track unresolved identity growth.
- Tighten rules where misuse appears.

Goal: Combine siloed data without hard-coding vendor logic.

How it works:
1) Each system returns its own data with source_system + source_id.
2) Identity Resolution stores canonical mappings across sources.
3) Orchestration joins results using mappings and emits provenance + source availability.

When vendors do not support joins:
- Use batch tools if available (preferred).
- Otherwise fan-out per ID (slower, but correct).
- If IDs do not line up, use fuzzy matching and flag confidence in trace.

What you should see in the trace:
- Source Availability warnings when a required system is missing.
- Identity Coverage (mapped vs unmapped).
- Provenance (which tools/retrievals produced output).