Workflow Intake Brief: Turn Messy Requests into Runnable AI Employee Work

A Workflow Intake Brief is the task-intake document that turns a vague request into a runnable AI employee workflow. It fixes the goal, Source Data, artifact, Trust Mode boundary, owner, schedule, and rejection conditions before Agent build begins. Teams every day throw repetitive, manual, time-consuming work at AI: "prepare a renewal analysis," "summarize competitors," "check these invoices." The problem is not that those tasks cannot be automated. The problem is that the request enters the workflow too loosely, causing error-prone rework, missing inputs, and repeated reruns. Axon's workflow-first route starts before the Agent runs.

Anthropic's Effective Context Engineering for AI Agents argues that context has to be curated for agents. Anthropic's Building Effective Agents also separates structured workflows from more open-ended agents. In Axon, the Workflow Intake Brief is where business intent, context, and execution boundary meet.

A useful AI employee does not start from a wish. It starts from a task brief that a Skill chain can execute and a business owner can accept.

Bad requests sound normal

Most bad workflow requests sound perfectly reasonable in conversation. They are risky because they leave the workflow guessing.

Vague request	What the workflow cannot know	What the brief must add
Check these customers	Which customers, what to check, what to deliver	Customer list, judgment criteria, artifact format
Send me an industry summary every week	Sources, time range, depth	Source Data, cadence, acceptance rule
Automate invoices	Extract, reconcile, archive, or approve	Skill chain, Trust Mode, exception owner
Write a follow-up email	Recipient, evidence, send boundary	Draft artifact path and approval rule

This is upstream of Context Packets. Context Packets organize runtime context for the Agent. A Workflow Intake Brief decides whether the task is clear enough to become a workflow at all.

A runnable intake brief

workflowIntakeBrief:
  request: "prepare renewal risk brief for top 20 customers"
  businessGoal: "help account owner decide renewal follow-up order"
  sourceData:
    required:
      - "customer list with renewal date"
      - "usage export for last 90 days"
      - "support ticket summary"
  artifact:
    type: "renewal-risk-brief.md"
    acceptance: "ranked customers, risk reason, suggested next action"
  trustMode:
    confirmBefore:
      - "send customer-facing email"
      - "update CRM field"
  owner:
    requester: "customer success lead"
    reviewer: "account owner"
  rejectIf:
    - "customer list missing renewal date"
    - "usage data older than 30 days"

The brief is not meant to be heavy. It answers one practical question: is this request ready to become an Agent Pipeline?

A brief is closer to business reality than a prompt

Teams often treat prompt writing as the start of automation. Prompts matter, but prompts mostly guide how the model responds. A Workflow Intake Brief defines why the business is authorizing the work.

The brief fixes the business goal first, then Source Data, artifact, and rejection rules. After that, System Skills, User Skills, and Trust Mode can be arranged around the task instead of around a temporary instruction. Think of it as the upstream partner to a Workflow Runtime Contract: intake decides whether the workflow is worth building; the runtime contract decides how it is allowed to run.

Requests that should not enter Agent Builder

The source boundary is unclear.
If the requester says "just find whatever is relevant," the task is still exploration, not a scheduled workflow. Fix Source Data fields first.

The artifact cannot be accepted.
"Make it professional" is not an acceptance rule. The artifact needs a type, fields, audience, and acceptance condition.

Risky actions have no approval boundary.
Outbound messages, deletion, publishing, customer-record updates, and file overwrites need Trust Mode in the brief, not as an afterthought.

A compact intake review

Step 1: ask what artifact will exist at the end of the workflow. Step 2: ask which Source Data is required and whether missing data should reject the request. Step 3: ask which actions need confirmation, authorization, or human handoff.

If those questions have answers, the task can move into the AI Workflow interface or Agent Builder. If not, the work is not ready for automation.

Intake Brief Questions

Q1: Does a Workflow Intake Brief slow down Agent building?
It adds a few minutes. It usually saves far more time by preventing reruns caused by wrong goals or missing data.

Q2: Who should write the brief?
The business requester supplies goal and acceptance. The workflow owner adds Source Data, Skill chain, and permission boundary. The model should not own the whole definition.

Q3: Do one-off research tasks need a brief?
Light exploration can be simpler. If the task will be reused, scheduled, or accepted by another owner, write the brief.

Rewrite one request before building

Pick one repeated task you usually give Axon. Do not start with the prompt. Write the goal, Source Data, artifact, Trust Mode, owner, and rejectIf conditions first. Explore Context Packets, Runtime Contracts, and the workflow interface, then build the AI employee. That small intake step makes the Skill chain more stable and makes the result easier for the business to trust.