# Architect this recurring AI process

Help me turn the process below into the simplest reliable AI system that can run repeatedly. Do not assume I need an autonomous agent or a workflow graph. Start with the smallest architecture that can meet the result, then add complexity only when you can name the failure it prevents.

## The process

- Business result: [What useful outcome should arrive?]
- Trigger or schedule: [What starts the work, and in which time zone?]
- Inputs: [Files, systems, websites, databases, messages, or human decisions.]
- Output: [Exact deliverable and destination.]
- Current manual steps: [List the steps as they happen today.]
- Rules and definitions: [Terms, thresholds, exclusions, brand voice, or policies.]
- Consequential actions: [Anything that sends, publishes, spends, edits, deletes, or changes access.]
- Expected volume: [Runs, records, files, or tasks per period.]
- Acceptable cost and delay: [Budget and delivery window.]
- What must be remembered: [Prior results, processed IDs, decisions, or nothing.]
- Human owner: [Who reviews failures and approves consequential actions?]

## Classify each part before designing it

Use these layers deliberately:

1. **Prompt:** one-off reasoning or generation that does not need a durable reusable procedure.
2. **Skill:** a bounded, repeatable procedure with stable instructions, inputs, and output. A skill explains how to perform work. It does not create a schedule, connection, or durable runtime by itself.
3. **Connector or MCP server:** access to current external data or tools. Keep authentication in the provider or secret store, never inside the prompt or skill.
4. **Workflow or graph:** predefined sequencing, branches, parallel work, handoffs, retries, gates, or aggregation. A graph may call skills at its nodes.
5. **Agent:** open-ended work where the necessary steps cannot be known in advance and environmental feedback must guide the next action.
6. **Schedule, loop, watcher, or event:** the trigger that starts or wakes the work. State what happens if a run is late, missed, duplicated, or overlaps another run.
7. **Durable state:** memory required across runs, including processed-item IDs, prior findings, checkpoints, and audit history.
8. **Approval gate:** a named human decision before sending, publishing, spending, deleting, editing live records, changing permissions, or taking another consequential action.
9. **Isolated execution:** a worktree, sandbox, temporary environment, or limited account when the work changes code, files, or systems.

## Decision rules

- Use one prompt when one prompt reliably produces the result.
- Create a skill only after the procedure has repeated enough to reveal stable steps and edge cases.
- Use a workflow graph when the process has branches, parallel research, dependencies, retries, or separate review stages.
- Use an agent when the route must change based on what it discovers. Bound its tools, time, spending, and stopping conditions.
- Give every recurring process a durable duplicate key when repeating an external action would cause harm or confusion.
- Prefer direct connectors over screen control. Use screen control only when a precise integration is unavailable and the risk is acceptable.
- Do not treat a successful tool call as a successful business outcome. Verify the final deliverable.
- Do not automate publication or other consequential delivery until a draft-only run has been inspected.

## Produce this deliverable

Return:

1. **Recommended architecture:** A short plain-language description of the minimum viable system.
2. **Layer map:** A table mapping every part to prompt, skill, connector, workflow, agent, trigger, state, approval, or isolation. Explain each choice.
3. **Flow:** A numbered run from trigger to verified result, including failure and retry paths.
4. **Skills to create:** For each proposed skill, give its purpose, trigger conditions, required inputs, steps, output contract, edge cases, and what it must not do.
5. **Workflow graph:** Only if justified. List nodes, transitions, branches, parallel work, gates, retry limits, and stopping conditions.
6. **Connections and credentials:** Current data sources, minimum permissions, credential location, and expiration or reauthorization behavior.
7. **State and deduplication:** What persists, where it persists, retention, and the duplicate key.
8. **Human controls:** What requires approval, who owns it, and what the approval screen or brief must show.
9. **Verification plan:** Tests for a normal run, missing data, stale credentials, partial failure, duplicate input, retry, and a missed schedule.
10. **Cost and operating limits:** Expected model, tool, and infrastructure costs with explicit assumptions. Label estimates as estimates.
11. **Build order:** The smallest draft-only version first, followed by the conditions that would justify each additional layer.
12. **First implementation step:** One concrete action we can complete now.

Flag unknowns. Cite current official documentation for platform-specific claims. Do not invent successful tests, available integrations, prices, permissions, or release behavior.