Source Data fields: turning one-off prompts into reusable AI digital employees

Source Data fields often decide whether an AI digital employee becomes reusable or remains a one-off prompt. Without fields, users manually paste background, files, recipients, deadlines, and output rules into long instructions every day. The process is repetitive, time-consuming, and error-prone; the next customer or project forces the user to explain everything again. The Model Context Protocol tools specification describes how servers can expose tools that models invoke, which is a useful reminder: as agent capabilities expand, input context must become more structured. See the MCP tools specification.

Fields are workflow interfaces

Source Data fields move “what changes in this run” out of the stable Agent instruction. The Agent brief should describe durable logic. Fields should carry customer name, source links, cutoff date, tone, template file, reviewer, and permission flags. That separation lets the same Agent run across different cases without asking the user to write a new prompt every time.

For the build path, read AI Build for the first Agent. For the run rhythm, use the Build Agent Autorun tutorial. When field design is strong, Skills, Agents, and Trust Mode can work together instead of depending on a fragile paragraph of instructions.

Good fields let users provide business variables. Bad fields push users back into prompt-writing work.

A reusable field schema

Source Data fields should define meaning, type, required status, example, and validation. The following customer follow-up Agent schema shows a practical pattern.

source_data:
  customer_name:
    type: text
    required: true
    example: "Acme Capital"
  meeting_notes:
    type: file
    required: true
    allowed: [".md", ".docx", ".pdf"]
  follow_up_deadline:
    type: date
    required: true
  tone:
    type: select
    options: ["formal", "concise", "warm"]
  reviewer:
    type: person
    required: true
  external_send_allowed:
    type: boolean
    default: false

1. Step 1: list the variables that change on every run.
2. Step 2: turn those variables into fields instead of embedding them in the Agent instructions.
3. Step 3: add type, example, and required rules for each field.
4. Step 4: instruct the Agent to ask for missing required fields rather than guessing.
5. Step 5: connect risk fields to Trust Mode, such as external send permission and reviewer.

Good fields versus weak fields

Required fields

Required fields decide whether the task can start. Customer name, contract version, cutoff date, output template, and reviewer should stop the run if missing.

Optional fields

Optional fields express preferences such as tone, summary length, sorting order, or whether to preserve original tables. They should not replace required business context or compliance boundaries.

Risk fields

Risk fields decide whether the Agent should ask for approval: external sending, overwriting files, or calling third-party systems. For a document-and-email example, see the Research PDF Email Agent workflow. For the capability base, return to the System Skills introduction.

Weak field	Why it fails	Better field
“Make it professional”	Cannot be validated	tone: formal
“Use recent materials”	Time range is vague	cutoff_date: 2026-05-22
“Send to the client”	Risk target is unclear	recipient_email + approval_required
“Use that template”	File cannot be traced	template_file: proposal-v3.docx

A useful quality check is to run the same Agent twice with different customers or projects. If the reviewer must rewrite the instruction both times, the field contract is incomplete. If the reviewer only changes values and receives consistent artifacts, the design is working. This test also exposes missing defaults: date ranges, file versions, reviewer names, and send permissions often look obvious to humans but remain invisible to the Agent until they become explicit inputs.

Field design should also be reviewed after real use. When users keep adding the same sentence to the notes area, that sentence probably deserves a proper field. When users ignore a field for several runs, it may be noise. The goal is a lean interface that captures business meaning, not a form that asks for everything.

FAQ

Q1: Should an Agent have as many Source Data fields as possible?

No. Fields should cover changing variables that affect the result. Too many preference fields create friction and confuse priority.

Q2: How are fields different from prompts?

The prompt describes durable task logic. Fields describe run-specific inputs. Separating them makes the Agent reusable.

Q3: What should happen when fields are missing?

Missing required fields should stop the run and trigger a question. Missing optional fields can use defaults. Missing risk fields should default to conservative behavior.

Q4: Should business users help design fields?

Yes. Business owners know which inputs change and which details affect acceptance. Field design built only from technical guesses often looks complete but fails in daily work.

Next step

Get started in Axon by taking one long prompt and converting it into six to ten Source Data fields. Run the same Agent with two different inputs, compare the outputs, and then learn more about Skills so the field schema becomes a reusable AI digital employee interface.