Build Your First AI Agent in 10 Minutes
The fastest way to understand an agent platform is to ship one small agent end to end — not read about it. In the next ten minutes you will build a support triage agent that reads a ticket, classifies it, and drafts a response, then watch its first execution trace. Nothing here requires code.
What you are building, and why this one
A support triage agent is the ideal first build for unglamorous reasons. The task is bounded — read, classify, draft — so you can judge output quality immediately without domain debate. It exercises every layer you will use later: a model, a tool, a guardrail, a trace. And its failure modes are cheap, because nothing sends without a human.
Before starting, sign in to your workspace and confirm you have a support integration available — Zendesk or Jira both work, and connecting one is a standard OAuth flow if you have not already. If your organization has not picked a tool yet, browse the integration catalog first. Then open Agents in the sidebar and click + Create Agent to enter the builder. The builder is nine steps, but only five need decisions today — defaults carry the rest.
Walk the builder
Work through the steps in order:
- Name it. “Support Triage Agent”, one-sentence description, category Support. Names matter more than they seem — this one will appear in run history and audit logs.
- Pick a model. Choose a fast, low-cost one — GPT-4o-mini, Claude Haiku, or your provider’s equivalent. Triage is a high-volume, low-complexity task; you can upgrade later and A/B the difference properly.
- Attach the tool. Add your Zendesk or Jira integration. This is what lets the agent read tickets and post updates — and note that capability comes from this attachment, never from the prompt.
- Skip skills, knowledge, memory, and voice. Defaults are fine for a first agent; each has its own guide when you need it.
Two steps remain — guardrails and publish — and they deserve their own sections.
Attach a guardrail before your first run
It is tempting to skip the Guardrails step for a toy agent. Do not — attaching one now costs a single click and builds the habit that matters most later. Pick the Standard preset: it catches abusive language, common jailbreak patterns, and PII leakage out of the box, which is exactly the trio a support agent meets first, since ticket bodies are raw, unfiltered user input.
The mental model to take away: the guardrail is not part of the prompt. It is a runtime inspector that scans every prompt, tool call, and response independently of what the model decides — so an instruction hidden in a ticket cannot talk the model out of it. Later, when the agent touches real customer data, you will layer a PII Redaction preset on top and tune actions per rule; the guardrails documentation covers that progression. For now, Standard is enough. Click Review and publish, confirm the summary, and publish.
Test it and read your first trace
Click Test on the agent card and paste a realistic ticket: “Customer says their invoice is wrong, urgent, mentions refund.” The response matters less than what is underneath it — expand the execution trace below the reply.
Learn to read its three parts now, while the stakes are zero. The LLM call shows the resolved prompt and completion — what the model actually saw, which is where most “why did it say that?” questions end. The tool invocation shows the ticket read with exact arguments — the record of the agent touching an external system. The totals show tokens, latency, and a per-run dollar cost. That cost figure on run one is quietly the most useful number on the page: multiply by projected volume and you have a credible pilot budget before anyone asks. Every production run records exactly this shape of trace in Monitor — the test panel is just the same instrument up close.
Where to go from here
You now have the full loop: build, guard, run, inspect. Three next steps, in the order that pays off fastest. First, send ten varied tickets through the test panel — including a hostile one and an ambiguous one — and note where the agent hesitates; those examples are the seed of your first eval dataset. Second, wrap the agent in a small workflow that adds an approval gate before any ticket update, so a human reviews writes from day one.
Third, when a teammate asks what you built, resist demoing the chat window and show the trace instead — the record of what the agent did is the thing that separates this from a chatbot, and it is the part production teams care about. From here, the getting-started track continues into agents, workflows, and governance in depth. Ten minutes in, you are past the demo stage most AI projects never leave.