Input: What Flows Into the Agent

OSLO tells you where an agent sits. FAST tells you how it runs. And every FAST loop — in any pillar — starts in the same place: Input. This is the raw signal the system acts on, the thing that arrives and says now there's work to do. Get this stage wrong and the most brilliant agent in the world produces nothing, because nothing reached it.

What Input actually is

Input is anything that crosses the threshold into your system:

• Data — a row added to a sheet, a new record in the CRM, a transcript that just finished processing, a file dropped in a folder.
• Requests — a human asking for something: a Slack message, an email to a shared inbox, a form submission, a "can you handle this?"
• Triggers — an event firing on its own: a payment succeeds, a calendar invite is accepted, a deadline arrives, a webhook lands.

The Architect's discipline at this stage is to make input clean and explicit. A vague trigger ("sometimes when things feel busy") can't be automated. A precise one ("when a deal moves to Closed-Won in the CRM") can. If you can name exactly what comes in and when, you can build a loop around it. If you can't, you don't have an input — you have a vibe.

How an Architect designs it

You don't process the input yourself; you decide what counts as one and how it arrives:

• Pick the trigger. What single, observable event should kick this loop off?
• Shape the payload. What does the agent need to see — the email body, the customer name, the order ID — to do the job without asking a follow-up?
• Set the gate. What's not an input? Filtering junk at the door keeps the agent from burning cycles on noise.

Worked example

You want a loop that handles new support tickets. The sloppy version says "when customers need help." That's unbuildable.

The architected version names the input precisely: trigger = a new message in the support inbox; payload = sender, subject, full body, and the customer's plan tier pulled from the CRM; gate = ignore auto-replies and internal CCs.

Now the input is a clean, structured signal — every time, in the same shape. The transformation agent downstream never has to guess what it's looking at, because you decided, up front, exactly what flows in. That precision is the whole game: the ceiling on what an agent can produce is set the moment the input arrives.

Sample prompts — design your Input with an agent

You don't have to architect this stage alone. Paste one of these into Claude (or any capable model) and let the agent push you on precision until the trigger is actually buildable.

Designing a new input:

I'm building a FAST loop in the [OFFER / SALES / LEADS / OPERATIONS] pillar. The job I want the loop to do is [one sentence]. Help me design the Input stage: what's the cleanest single observable event that should kick this off, what payload should the agent see when it fires (so it never has to ask a follow-up), and what should we filter out at the gate? Push back if any of my answers are vague — "when things feel busy" isn't a trigger.

Auditing an input you already have:

Here's a loop I'm running today: [describe it]. The current trigger is [...] and the payload is [...]. Audit this Input stage — is the trigger precise enough to automate, is the payload complete enough for the agent to work without follow-up, and is the gate filtering the right noise? Tell me where it's still a vibe instead of a signal.