Inputs, outputs and constraints

By the end, you can

• Define a bounded task's inputs and outputs in explicit, checkable terms rather than an implied scope (LA-2).
• Name the constraint kinds that keep a task's inputs and outputs bounded, and apply them to a sample task (LA-2).

Before you start

This is Module 2, Lesson 1 of the Local AI Agents course. It assumes Module 1's three lessons: the five boundaries — task, data, tool, authority, and time-and-cost — from Lesson 1; the automatic / approval-required / out-of-scope classification from Lesson 2; and the excessive-functionality and excessive-permissions distinction from Lesson 3. This lesson does not re-teach those. It uses them to build the first piece of a bounded task brief: an explicit statement of what a task consumes and what it must produce.

A task brief starts with what goes in and what comes out

"Summarize the tickets" is not a task brief — it is a hope. It does not say which tickets, over what period, in what format, or who reads the result. A model given that sentence has to guess the input scope and the output shape, and a guess made silently is a guess you cannot review before the run starts.

Anthropic's prompt engineering guidance names the fix directly: treat the model "as a brilliant but new employee who lacks context on your norms and workflows" and be "specific about the desired output format and constraints." A vague instruction is not efficient because it is short — it is expensive because someone has to inspect the output afterwards to discover what was actually assumed.

• Inputs are what the agent is given or allowed to fetch before it starts producing anything.
• Outputs are what the agent is required to hand back when it stops.
• Neither should be left to be inferred from the model's judgement of what "summarize" or "clean up" probably means.

Inputs need an explicit boundary, not an implied one

A task's inputs are not just "the data it needs" — they are the exact data it is allowed to touch, and nothing wider. This is the same principle Module 1 covered for tool grants, applied here to the data a task consumes. OWASP's guidance on excessive agency defines excessive permissions as "an LLM extension has permissions on downstream systems that are not needed for the intended operation" — a task whose inputs are "the whole shared drive" when it only needs one folder's contents carries that same unnecessary exposure, whether or not anything goes wrong.

A bounded input statement names four constraint kinds:

Leaving any of these four to be inferred means the actual input boundary is whatever the model happens to fetch, not what you decided it should fetch.

• Source — exactly where the data comes from (a named folder, a named export, a named API endpoint).
• Scope — which subset of that source is in play (a date range, a set of fields, a set of record IDs).
• Retention — whether the agent may keep the data after the run, or must discard it when the task ends.
• Sensitivity — what must never be included, even if it is technically present in the source (customer identifiers, credentials, health or financial detail).

Outputs need a checkable shape

An output is not just "the answer" — it is a specific artifact bounded by three more constraint kinds, and all three should be decided before the run, not discovered after it.

Together, those seven — source, scope, retention and sensitivity on the input side; shape, destination and side effects on the output side — are the constraint kinds a bounded task brief states explicitly, and the vocabulary the rest of this module builds on.

OpenAI's guidance on building agents names instructions — including the context and format an agent is given — as one of an agent's three core components, alongside the model and its tools. An output requirement is part of that instruction, not an afterthought bolted on after the model has already produced something. If the output's shape is decided only by looking at what came back, there was never really a specification, only a reaction to whatever happened.

• Shape — the format and structure the output must take: a markdown table, a fixed set of sections, a maximum length.
• Destination — who or what receives the output: a file on disk, a draft awaiting review, a chat reply nobody else sees yet.
• Side effects — whether producing the output changes anything outside the task itself, such as writing a file, posting a message or updating a record.

Worth naming, saved for later: whether the output is actually correct

This lesson defines the shape of a task's inputs and outputs. It does not yet ask how you would check that a completed output is actually right — that is acceptance criteria, the next lesson. Keep the two separate: "the output is a markdown table with these three columns" is a shape requirement you can write here; "the numbers in that table are correct" is a claim you can only check against evidence, which is where Lesson 2 picks up.

A worked example: from a vague ask to a bounded input/output statement

Vague version: "Summarize this week's support tickets."

Bounded version:

Notice what this version makes possible that the vague version did not: a reviewer can check the input scope and the output shape before a single ticket is read, instead of reconstructing them from whatever the agent happened to produce.

• Input source: the ticket export CSV for the current week, generated by the support tool's own export feature.
• Input scope: rows with a creation date inside the current calendar week; the columns `ticket_id`, `subject`, `category`, `status`, `created_at` only.
• Input sensitivity: customer names, email addresses and message bodies are present in the export but excluded from what the agent reads — it works from the five listed columns only.
• Input retention: the export is read for this run and not retained afterwards.
• Output shape: a markdown document with one table (columns: category, count, example ticket ID) and a two-sentence summary paragraph.
• Output destination: a draft file in a review folder, not sent or posted anywhere.
• Output side effects: none — the task only produces the file; it does not close, tag or reply to any ticket.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Prompting best practices — Anthropic (Claude Docs). Being specific about desired output format and constraints, and treating the model as a new employee without shared context, produces more reliable results.
2. A practical guide to building agents — OpenAI. Names instructions, with their context, as one of an agent's core components alongside the model and its tools.
3. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Defines excessive permissions as access beyond what the intended operation needs — the same scoping principle applied here to a task's data inputs, not only its tools.