Identify the capability each business need calls for
A recommendation starts with what the business needs the agent to do. Each need asks the agent for one of three things: an answer based on content it can reference, a result or change in another system, or work that a specialist handles. These map to three agent components: knowledge, a tool, and a connected agent. Sorting each need into one of these is the first step toward recommending an integration approach.
Map integration approaches to use cases
A system's name doesn't tell you how to integrate it, because the same system can serve different needs. For example, a service management system might hold reference articles that an agent uses to answer questions, and also hold records that the agent creates or updates. The articles call for knowledge, and the record changes call for a tool.
To choose a component, describe what a good response looks like. Does the agent answer from content, return or change something in a system, or pass the request to a specialist?
For example, your operations team's four needs map to components this way:
| Example request | What it asks for | Component |
|---|---|---|
| "What does the current escalation policy say?" | An answer from reference content | Knowledge |
| "What's the status of case 204?" | Current data from the case system | Tool |
| "Submit the approved update for case 204." | A change in the case system | Tool |
| "Ask the specialist to assess this exception." | Judgment from a separate specialist | Connected agent |
Answer questions with knowledge
Knowledge gives the agent content to ground its answers. When you build the agent, you add knowledge sources such as uploaded files, SharePoint sites, public websites, or articles from other business systems, so every user gets answers from the same content. When a question calls for it, the agent searches that content and uses what it finds to respond.
Knowledge fits questions whose answers already exist in documents or articles, such as policies, procedures, and reference information. For your team's policy question, the approved policy documents are a natural knowledge source, provided someone keeps them current.
Look up current data and take action with tools
Tools let the agent work with other systems during a conversation: retrieve current data, create or update records, send messages, or run a process. When a request depends on the current state of a record, needs data specific to the person asking, or asks the agent to make a change, a tool is the likely fit.
A tool can read data, write data, or both. Retrieving a case's current status is a read; submitting an approved update is a write. Keep the two apart as you plan, because reading and writing can need different access. Permission to read case records doesn't necessarily include permission to change them.
"Knowledge for answers, tools for actions" is a useful starting point, with an exception worth knowing: a tool can also answer questions when another team already built the search over the content. Foundry IQ works this way. A Foundry IQ knowledge base bundles data sources with retrieval and relevance settings that a team built and tuned, and you add it to your agent as a tool so your agent reuses that setup. Knowledge remains the usual fit when your agent answers from content. Foundry IQ is the exception to consider when a team in your organization already maintains a tuned knowledge base for that content.
Hand off specialist work to a connected agent
A connected agent is another agent that your agent can pass a request to. The connected agent works with its own instructions, knowledge, and tools, and returns its response to your agent, which presents it to the user.
A connected agent fits when the specialist work differs enough from the rest of your agent's work to justify a separate agent. Look for one or more of these signs:
- The work draws on its own knowledge and tools, in a domain your agent doesn't otherwise cover.
- The work needs different access or governance than the rest of your agent.
- Several agents need the same capability, so one specialist agent can serve all of them.
- Another team owns the specialist agent and updates it independently.
If none of these signs applies, keep the work in your agent. Each separate agent adds design, testing, and maintenance effort, so start with one agent and add a connected agent when you see a clear need. If your agent needs only one more source of data, a knowledge source or tool may be the simpler choice.
For example, if another team maintains an agent that assesses exceptions against its own rules and resources, your agent can pass unusual cases to it. Routine case lookups stay with your agent.
Combine components in one agent
Agents often use several components together. In the utility scenario, the case management agent your operations team asked for needs all three: knowledge for policy questions, tools for case lookups and updates, and a connected agent for exceptions. A single request can also need more than one component, such as explaining a policy and then updating a case.
Agents can also have skills, which package instructions for handling a specific kind of task, such as applying a review checklist. A skill shapes how the agent carries out a task instead of connecting it to another system, so it isn't an integration choice. Skills matter when you write the descriptions the agent uses to decide which capability to apply.
Reflect: Think of a system your team uses every day, such as a ticketing, HR, or finance system. Which integration approach would be appropriate based on how your agent would need to interact with the system?