course module

Output: What the Agent Ships

The third stage of the FAST loop. Output is the finished result delivered where it needs to go — a sent message, an updated record, a shipped asset. Work that doesn't land somewhere isn't output; it's a draft nobody asked for.

ai-tools free

The Transformation Agent did the work. Output is where that work lands. This is the stage founder-architects underrate, because it feels like the easy part — the agent already did the thinking, surely shipping it is trivial. It isn't. Output is where most homemade automations quietly fail: the agent generates something beautiful and then leaves it sitting in a log nobody reads. Work that doesn't arrive somewhere useful isn't output. It's a draft talking to itself.

What Output actually is

Output is the result, delivered to its destination in the form that destination needs:

A sent message — the email that actually reaches the customer's inbox, the Slack alert that hits the right channel.
A changed system of record — the CRM field updated, the invoice marked paid, the row written, the status moved.
A shipped asset — the post published, the document filed, the report dropped where the team will see it Monday morning.

The Architect's discipline here is to be ruthless about the destination and the format. "Generate a reply" is not output. "Send the reply to the customer" is. The verb that matters is always a delivery verb: send, write, publish, update, post. If the loop ends in "produce," it doesn't end — it stalls.

How an Architect designs it

You decide where the work goes and in what shape it has to arrive:

Name the destination. Exactly which inbox, channel, record, or surface does this land in? Ambiguity here is where output evaporates.
Match the format. A CRM wants structured fields; a customer wants a human sentence; a dashboard wants a number. Same result, three different shapes.
Confirm the landing. Did it actually arrive? A loop that can't tell delivery from failure is a loop you can't trust to run unattended.

Worked example

Back to the support ticket. The agent has drafted a reply in your voice. Now Output does the part that makes it real: it sends the response to the customer, logs the interaction against their record in the CRM, and tags the ticket resolved — or, if the issue needs a human, routes it to the right person with the draft attached.

Three destinations, three formats, one delivered result. The customer got an answer, the system of record is current, and the team can see exactly what happened. That's a closed loop — not because the agent was clever, but because the Architect made sure its work landed instead of evaporating into a log.

Sample prompts — design your Output with an agent

Same move as the Input stage: hand the question to a capable model and let it press you until the output is actually defined.

Designing a new output:

The loop I'm designing produces [what the Transformation Agent generates]. Help me architect the Output stage: exactly where should this land (which inbox / channel / record / surface?), what shape does it need to arrive in at that destination, and how will the loop confirm delivery so I can trust it to run unattended? Push back if I use the verb "produce" instead of a delivery verb like send, write, publish, update, or post.

Auditing an output you already have:

Here's a loop that's already running: [describe it]. The current output is [describe what it produces and where it goes]. Audit this Output stage — is the destination unambiguous, is the format right for that destination, and can the loop actually tell delivery from failure? Tell me where the work is still evaporating instead of landing.

Next up

Human-in-the-Loop: The Feedback Step That Makes It CANI

The fourth stage of the FAST loop and the one that makes it a loop at all. Human-in-the-Loop is the Architect reviewing, correcting, and raising the bar — the feedback step that turns a one-shot automation into constant, never-ending improvement.

What Output actually is

Output is the result, delivered to its destination in the form that destination needs:

A sent message — the email that actually reaches the customer's inbox, the Slack alert that hits the right channel.

A changed system of record — the CRM field updated, the invoice marked paid, the row written, the status moved.

A shipped asset — the post published, the document filed, the report dropped where the team will see it Monday morning.

How an Architect designs it

You decide where the work goes and in what shape it has to arrive:

Name the destination. Exactly which inbox, channel, record, or surface does this land in? Ambiguity here is where output evaporates.

Match the format. A CRM wants structured fields; a customer wants a human sentence; a dashboard wants a number. Same result, three different shapes.

Confirm the landing. Did it actually arrive? A loop that can't tell delivery from failure is a loop you can't trust to run unattended.

Worked example

Sample prompts — design your Output with an agent

Same move as the Input stage: hand the question to a capable model and let it press you until the output is actually defined.

Designing a new output:

The loop I'm designing produces [what the Transformation Agent generates]. Help me architect the Output stage: exactly where should this land (which inbox / channel / record / surface?), what shape does it need to arrive in at that destination, and how will the loop confirm delivery so I can trust it to run unattended? Push back if I use the verb "produce" instead of a delivery verb like send, write, publish, update, or post.

Auditing an output you already have:

Here's a loop that's already running: [describe it]. The current output is [describe what it produces and where it goes]. Audit this Output stage — is the destination unambiguous, is the format right for that destination, and can the loop actually tell delivery from failure? Tell me where the work is still evaporating instead of landing.