Agent Studio20 min readAppian 26.7

Build Your First Appian AI Agent

Click by click, in Appian Designer. We'll build an agent that reads a customer email, looks up their account, checks policy, and either replies or escalates to a human — then drop it into a process model with the Execute AI Agent smart service.

Create the agent Instructions Tools Inputs & outputs Test & read Into a process

Before you start: it has to be switched on

AI agents are not enabled by default. If NEW > AI Agent isn't in your Build view, your environment doesn't have them yet — your Appian account team turns that on. Everything below assumes Appian 26.7; the UI moved noticeably between 25.4 and 26.x, so older walkthroughs will not match your screen.
Watch it first (10 min)— Appian's own Agent Studio walkthrough

Your progress

0 of 6 done

1Create the agent

Open your application in Appian Designer, stay in the Build view, and click NEW > AI Agent.

Appian Designer
NEW ▾Build
Interface
Process Model
Record Type
Expression Rule
AI Agent
Connected System
Illustration of the Build view menu — NEW ▸ AI Agentsee the real screen

The create dialog asks for a Name, an optional Description, and — new in 26.x — an Agent Type. That choice decides where the agent can run, so get it right now:

Process Agent

Runs inside a process model via the Execute AI Agent smart service. No human in the loop while it works — it takes an input, reasons, acts, and returns structured outputs. This is what we're building, because inbox triage should happen without anyone watching.

Appian Designer

Create AI Agent

TTC_CustomerRequestIntake
Evaluates incoming customer request emails, decides next steps, updates records, and drafts the reply.
Process AgentChat Agent
CANCELCREATE
Illustration of the Create AI Agent dialogsee the real screen

Name it like a design object, not a robot

Keep your app prefix and describe the job: TTC_CustomerRequestIntake. You'll be reading this name in a process model node and an audit trail later — “Aiden” will not help you then.

2Write the instructions

This is the whole brain of the agent, and it's just text. In 26.7 the Instructions field takes Markdown, and there's a Preview tab to see it rendered. Structure beats prose — headings give the model clean boundaries between who it is, what it does, and what it must never do.

Instructions (Markdown)
## Role
You are a customer service agent for a telecom provider.

## Task
Read an inbound email from an existing customer, gather what you
need using your tools, and take exactly one action.

## Steps
1. Look up the customer record before anything else.
2. Read their account type and the packages they hold.
3. Check the request against the relevant policy document.
4. Choose ONE action plan:
   - **Answer** — a general question. Reply with the answer.
   - **Refund** — verify eligibility against the refund policy
     first. If eligible, raise it and return the refund ID.
     If not, explain why, quoting the policy.
   - **Service ticket** — something is broken or needs changing.
     Raise the ticket and return its ID.
   - **Escalate** — meets the escalation criteria. Flag for a
     human and do not reply on your own.

## Rules
- Verify the customer exists before taking any action.
- Never issue a refund without checking eligibility first.
- If the request fits no plan cleanly, escalate rather than guess.

Write the escape hatch first

That last rule does the heavy lifting. An agent with no “when unsure, escalate” instruction will always invent something — that is what a language model is built to do. Deciding what it must not handle alone is the difference between a demo and something you put in front of customers.

3Add tools

A prompt with no tools is a chatbot. Tools make it an agent. Click ADD TOOL, pick the design object, and it appears in the Tools list with its description — which the agent reads to decide when to use it. There's also an External Tools tab for MCP servers, if you need the agent to reach something outside Appian.

Appian Designer
Tools+ ADD TOOL
Escalation PolicyWhen to hand a request to a humanDocument
Refund PolicyWho qualifies for a refund, and for how muchDocument
CustomerStores data about customersRecord Type
Acquired PackagePackages each customer currently holdsRecord Type
Create or Update Refund RequestRaises a refund requestProcess Model
Create or Update Service RequestOpens a support ticketProcess Model
Illustration of the Tools section after adding six toolssee the real screen

Knowledge tools — read only

Documents hold your policies, so the agent quotes real rules instead of inventing plausible ones. Record types are how it finds out who is emailing and what they already have.

Action tools — they write

Process models let it actually do things — raise a refund, open a ticket, update a record. The agent decides whether to run one; your process still controls how, including validation and security.

Keep action processes boring

Give it process models that do one thing and write one record type — no child processes, no chained side effects. When an agent misfires during testing, and it will, you want the blast radius to be a single row you can delete.

The description is part of the prompt

The agent picks tools by reading their descriptions. A record type described as “Stores data” tells it nothing. “Packages each customer currently holds” tells it exactly when to reach for that tool. Vague tool descriptions are the most common reason an agent ignores a tool you gave it.

4Define inputs and outputs

Click + ADD in each section. Inputs are what the agent receives; outputs are the structured values it must produce. Outputs are what turn free-form reasoning into something a process model can branch on — without them you'd be parsing prose.

Appian Designer
Inputs+ ADD
AbccustomerRequestEmailTextREQUIRED
Outputs+ ADD
123customerIdNumber (Integer)
AbcemailResponseText
0/1manualReviewRequiredBooleanREQUIRED
Illustration of the Inputs and Outputs sectionssee the real screen

Name them for the process model, not the prompt

manualReviewRequired reads clearly as a gateway condition six months from now. flag does not. These become process variables — you're naming them for whoever debugs this later.

5Test it — and read the reasoning

Paste an input in the Test pane and click TEST. It may take a couple of minutes. What comes back is the most useful thing in Agent Studio: a step-by-step trace of every tool it called and why it chose what it did. Save each run with SAVE AS TEST CASE — that set becomes your regression suite.

Test input — customerRequestEmail
I've had enough. I've been with you for years and I've been
double charged AGAIN this month. Every time I call I get passed
around for an hour and told someone is "looking into it".

- Y. Tanaka
Appian Designer

Step 5 — Run Completed ✓

Reasoning

  1. 1. Retrieved the customer record from a partial signature (“Y. Tanaka”)
  2. 2. Retrieved their active package and billing history
  3. 3. Analysed the request against the Escalation Policy
  4. 4. Matched two escalation criteria:— recurring billing fault across cycles— long-tenured customer expressing strong frustration
  5. 5. Set outputs:customerId: 1manualReviewRequired: trueemailResponse: <explains escalation>

Note what it did not do: issue the refund. Repeat billing failure from a loyal customer is a retention conversation, not a transaction.

Illustration of the Agent History trace for this run

It won't do the same thing twice

Agents are non-deterministic. Run the same email twice and the steps can differ. So never test once and call it done — re-run your whole saved set after every instruction change, and check the Monitor tab to see tool calls and run history over time.

6Drop it into a process model

An agent on its own is a clever test pane. Grab its UUID from Settings > Properties, then add an Execute AI Agentnode to your process model and paste it into the Agent UUID input.

Start formExecuteAI AgentParseoutputsmanualreview?Manual Reviewhuman taskEmail Customeragent's replytruefalse

Passing inputs in

Map keys must match your agent's input names exactly.

Agent Inputs
a!map(customerRequestEmail: pv!customerRequestEmail)

Unpacking outputs

The node returns Agent Outputs (a Map), Run Summary and Run ID. A script task splits the map into process variables.

Parse Agent Outputs — three custom outputs
rule!getCustomerById(pv!AgentOutputs.customerId)
pv!AgentOutputs.emailResponse
pv!AgentOutputs.manualReviewRequired

The branch that matters

A gateway on pv!manualReviewRequired routes to a human task or straight to the customer.

Email body
if(
  pv!manualReviewRequired,
  "Thanks for contacting us. Here's what happens next: "
    & pv!manualReviewNextSteps & ". " & pv!manualReviewRationale,
  pv!emailResponse
)

Pass the Run Summary to your reviewer

The smart service hands back a run summary for free. Feed it into the manual-review task form and your reviewer opens a screen that already explains what the agent found and why it stopped — instead of a bare email and no context. It's the highest-value thirty seconds of configuration in this whole build.

Common questions

Getting asked about Appian AI in interviews?

Practise the questions that actually come up — agents, Data Fabric, Copilot and the rest.

Browse Appian interview questions

Sources & further reading

The UI walkthroughs on this page are our own illustrations built from the official documentation, not Appian screenshots — follow the “see the real screen” links for those. AppianVerse is an independent community platform, not affiliated with or endorsed by Appian Corporation. Appian® is a trademark of Appian Corporation.