An agent can discuss equipment requests all day. When someone asks it to submit one, the job changes. An answer is text. A submission is a record that either exists in the target system or doesn't.
Prompts, calculations, connectors, flows, and cards let an agent move beyond conversation. They don't all prove the same thing. In this lesson, you'll choose each tool by the operation it performs and reserve success language for results the responsible system has confirmed.
An agent that only chats has one move. Give it tools and it can retrieve, calculate, transform, and act. Each capability has a job, and reaching for the wrong one is how agents end up claiming work they never did.
Use the smallest tool that fits the operation. Choose a prompt to reshape text, a connector for one service operation, and a flow when several steps must be coordinated. Generated text does not establish that an external action occurred. If an agent must create, update, send, or delete something, it may report success only after the responsible connector or flow confirms the result.
A realistic request often combines several tools. A custom prompt normalizes messy input, a topic collects missing values, and a flow validates the completed request before calling the service. The topic should display only the result that the flow confirms. Everything before that confirmation is preparation.
Custom prompts need hard source boundaries
A custom prompt is a reusable instruction that takes supplied content and returns a constrained response. Build it from four elements you already know from prompting fundamentals: goal, context, source, and expectations. Make the expectations strict. Fixed headings, a hard word limit, an explicit source boundary, and a rule for missing information turn a vague "summarize this ticket" into something you can verify. The rule that pays for itself is the missing-value policy: tell the prompt to write "Not provided" under any heading the source doesn't fill, so a gap shows up as a gap instead of a plausible invention.
Some jobs aren't text at all. They're arithmetic. When a prompt must total, average, or compare numbers, use its code interpreter, which runs Python instead of estimating. But calculation has its own footgun: bad input. Define the invalid-value policy before you calculate. A missing or nonnumeric value should produce a validation error that names the offending line and performs no calculations. Never a total that treated a blank as zero. Code interpreter proves the math. It doesn't prove a business record exists.
Trustworthy flows report real outcomes
An agent flow is a workflow the agent calls as a tool. Treat its interface as a contract: named inputs, validation and other actions, named outputs, and clear failure behavior. The outputs should distinguish the terminal paths, such as submitted, invalid input, and not submitted. The topic that calls the flow shouldn't have to infer which path occurred.
When required values are missing, return the names of all empty inputs together. The topic can then ask for those values and call the flow again. Return success only when the operation's documented result confirms it and includes an identifier. If the destination supplies no identifier, report "not submitted." An example identifier is never a substitute for the value returned by the system.
Test each terminal path while the flow still stands alone: one missing input, several missing inputs, a simulated success, and a simulated failure. Once the flow sits behind a polished topic, basic faults are harder to see.
Adaptive Cards need an honest data path
An Adaptive Card presents related values under stable labels, which is easier to scan than a paragraph. The way to build one you can trust is to keep three layers separate. Data supplies source values and transforms them into display-ready ones. Presentation decides the title, labels, order, and which variable each field binds to. Behavior handles interaction after rendering, like a submit action. Build and verify them in that order, and keep display rules from rewriting source values: preserve the original record and create separate display variables for transformed values.
That separation is what makes failures diagnosable. Suppose your transform correctly turns a status of "Resolved" into "Closed," but the card still shows "Resolved." Because the correct value reached the presentation boundary but failed to render, the evidence points to presentation. The visible field probably still uses the raw status variable. Point it at the display variable while leaving the correct data unchanged. If the display variable itself contained "Resolved," the evidence would point to the data layer. Inspect which layer holds the wrong value before you change anything.
One more honesty rule: a card previews a planned route or a current state. It cannot prove that an action behind it occurred. And the text you sketch on paper is an assessable representation of the card's content. You cannot paste it into a message and expect it to render as a card.
Before moving to Autonomous Agents, Testing, and Publishing, take one flow you've built and locate the status and identifier returned by its final action. If either is missing, record the action as unconfirmed and fix the output contract before the agent runs unattended.
