Guides

Build a multi-tool agent

Create an agent that combines core tools, workflow tools, trace inspection, and a focused tool set.

This guide builds a practical agent that can answer questions, search records, run research, and call a workflow tool when the user asks for a controlled action.

What You'll Build

A Deal Prep agent that can:

  • Look up records.
  • Research an account.
  • Call a published workflow tool.
  • Explain what it found.
  • Show trace output so you can verify tool usage.

When to Use This

Use this when a simple one-tool agent is not enough, but you still want a constrained and testable assistant.

Good examples:

  • A page-aware assistant for account or opportunity pages.
  • A Slack or Teams agent for sales managers.
  • A meeting-prep assistant.
  • An agent that can launch workflow tools from chat.

Estimated time: 25-40 minutes.

Concepts used: Agents, Workflows vs. agents, Use a workflow as a tool.

Prerequisites

  • A published workflow tagged Use as Tool.
  • A clear job for the agent.
  • A small list of tools the agent actually needs.
  • Sample records to test against.

1. Define the Agent's Job

Write one sentence that explains what the agent is responsible for.

Example:

Help reps prepare for an upcoming opportunity meeting by finding account context, recent activity, and recommended next actions.

If the job needs five unrelated responsibilities, split it into separate agents or separate workflow tools.

2. Choose Core Tools

Add only the core tools the agent needs.

Common choices:

  • product_help for GTM Engine product questions.
  • search_records for finding accounts, contacts, or opportunities.
  • search_reports or report-preview tools for saved report context.
  • research_web for grounded external research.
  • navigate_to_record when the answer should include a link to a GTM record.

Start with fewer tools than you think you need. Add more only after a test shows a real gap.

3. Add a Workflow Tool

Add one workflow tool that performs the controlled action.

For a Deal Prep agent, that might be an Account Research workflow with:

  • Input: account_id
  • Output: research_summary
  • Output: recommended_next_step

The workflow should own the repeatable process. The agent should decide when to run it and how to explain the result.

4. Write the System Prompt

Keep the system prompt stable and role-focused.

Example:

You are a Deal Prep assistant for GTM Engine users. Help the user understand an account or opportunity before a meeting. Use tools only when they are needed. Prefer record search before asking the user for ids. When account research or next-step generation is requested, call the Account Research workflow tool. Explain what you did and cite the records or research you used.

Avoid putting long business processes in the prompt. If the process has fixed steps, put it in a workflow tool.

5. Configure Inputs

Declare inputs the agent expects from callers, such as:

  • user_id
  • account_id
  • opportunity_id
  • page_context

For page-aware agents, page context often supplies the record id. For Slack or Teams agents, the agent may need to search records by name first.

6. Test Tool Selection

Open the agent's Test tab and try prompts that should use different tools:

What does Acme do?
Research Acme and suggest my next step before tomorrow's meeting.
Open the opportunity record for the Acme renewal.

Inspect the trace:

  • Did the agent call the expected tool?
  • Did it pass the right structured inputs?
  • Did it avoid unnecessary tools?
  • Did it explain the result clearly?

7. Reduce Tool Scope

If the agent wanders, remove tools before rewriting the whole prompt.

Signs the tool set is too broad:

  • The agent calls research when record search was enough.
  • The agent calls a workflow for simple Q&A.
  • The agent runs multiple tools and then ignores their outputs.
  • The agent asks for ids that it could find with search.

The best agents have a clear job and a small set of high-confidence tools.

8. Publish and Monitor

Publish the agent once the trace matches your expectations.

After publishing:

  • Test from the surface where users will actually run it.
  • Watch early conversations for confusing prompts or tool misuse.
  • Remove or rename tools that users do not understand.
  • Move repeatable action logic into workflow tools as it matures.

Success Check

You are done when:

  • The agent uses core tools for lookup and context.
  • The agent calls the workflow tool only for the intended action.
  • Tool inputs are correct in the trace.
  • The final answer explains what happened.
  • The tool set is small enough to test confidently.

Common Pitfalls

  • Giving the agent every available tool.
  • Hiding required business logic in the prompt instead of a workflow.
  • Naming workflow tools too generically.
  • Testing only happy-path prompts.
  • Publishing before checking the trace.

Next Steps

On this page