# How to write an SOP an AI agent can follow How-to · By Nolli research, The Nolli team · Published 2026-10-18 · Updated 2026-10-18 · Prices and features checked 2026-10-16 Canonical page: https://withnolli.com/blog/how-to-write-an-sop-an-ai-agent-can-follow **Short answer.** Write down what a person would fill in from experience. An SOP an AI agent can follow states the trigger that starts it, the inputs it needs, the steps with one action each, a rule for every judgment call, the conditions where the agent stops and who gets the case, and a check that proves the result. Then test it in shadow mode. ## Key takeaways 1. A human SOP leaves out the judgment calls and exceptions that a person fills in without noticing, and an agent fills them in with a guess. 2. Write six parts: the trigger, the inputs, the steps, the decision rules, the stop and hand-off conditions, and the check that proves the work is right. 3. Lock whatever moves money, changes records or sets a threshold, explain the reason for the rest, and test the SOP in shadow mode on cases either side of every threshold. An SOP an AI agent can follow leaves nothing to guess. When a person reads “check the invoice against the purchase order”, they fill in a dozen details from experience without noticing. An agent fills the same gaps with a confident guess, and nothing tells you it guessed. So you write the details down. An SOP, or standard operating procedure, is a written, step-by-step description of how a task is done. We follow one small SOP through this whole post: what to do with a supplier invoice whose prices do not match its purchase order. It is an illustration. The steps, thresholds and roles are invented, and yours will come from your own work. Everything we say about outside guidance comes from eight public pages we read in full on 2026-10-16. We tested no product. Where the pages disagree, we say so and say which way we lean. This post supports our guide How to write a PRD for an AI agent. The PRD says what to build and how to judge it. The SOP says how the work is done, and the agent works from it. Both should come from the same map of how the work really runs. ## What a person fills in without noticing Think of directions to your house. To a friend you say “turn left at the blue gate”, and the friend knows the blue gate. A courier with only a map needs the street number, which side of the road, and what to do if the gate is shut. It is the same trip with a different document. An SOP written for a colleague is the blue-gate version. Here is the blue-gate version of our example step: “Check the invoice against the purchase order. If something looks off, sort it out with the buyer.” A clerk who has done the job for a year reads that and silently adds a lot. - “Looks off” means more than a small rounding difference. Nobody wrote down how small. - Big invoices skip this step and go to the accounts payable lead. - An invoice from a supplier who is not set up yet goes to a different team. - “Sort it out” means write to the buyer, and never promise the supplier anything. - When there is no purchase order, you stop and ask. Those are judgment calls and exceptions. The SOP leaves them out because its reader already has them. Our thesis for the rest of the post: an agent needs every one of them written down. The sources we read say the same thing in different words. Pro Sulum says people fill gaps with judgment and an agent fills them with a guess. Agently says most SOPs are written for people who already know the job, while agents share none of that unspoken context. Tallyfy says the version that reads cleanly to a veteran is the one that strands a machine, and that a process clear enough for an agent is clear enough for a new hire in week one. > **A two-minute test** Hand your SOP to someone who has never done the job and ask what they would do first. Wherever they hesitate, there is a blank. Anthropic’s prompting guide gives the same test for prompts: show it to a colleague with little context, and if they would be confused, the model will be too. Do this today with your first draft. ## The six parts, in the order you write them Agently lists a trigger, inputs, steps, edge cases and a verification check. AWS adds scope, case states and a never list. Pro Sulum asks for a named tool, an output and a success check on every step. Merge the three and you get six parts. The last three are where the unwritten judgment lives. **The anatomy of an SOP an agent can follow** 1. **Trigger**: What starts it, and what looks similar but does not. 2. **Inputs**: Each one named, with its source and what to do if it is missing. 3. **Steps**: One action each, naming the tool the step may use. 4. **Decision rules**: Every “it depends” written as if, then, else. 5. **Stop and hand off**: When to stop, who gets the case, what to send them. 6. **Check**: The proof the work is right, in terms someone else can verify. Our merge of the Agently, AWS and Pro Sulum structures. The highlighted parts are the ones a human SOP most often leaves to the reader’s experience. 1. **Write the trigger.** Name the exact event that starts the SOP: a status, a field value, a message. Then name the near-misses that do not start it and say where they go. Agently’s weak trigger is “as needed”; its strong one names a status and an amount. It also says to split by trigger, so one SOP covers one starting event. In our example: start when an invoice has the status price exception. An invoice marked no PO belongs to a different SOP. AWS adds a small guard worth copying: set the case to “in processing” first, and if it already is, back off. Do this today: Do this today: write the trigger as one sentence that contains a field name. 2. **List the inputs.** For each input, write its name, where it comes from, its format and what to do if it is missing. Precise names help: Pro Sulum’s example prefers order_id to “the order”. Agent Process adds a data rule. Everyone who works a step sees the whole run’s data, so keep bank details and secrets in the systems that own them and pass references. In our example the inputs are the invoice line prices, the matching purchase order line prices (read-only, from the ERP) and the supplier’s status in the vendor list. Do this today: Do this today: open the last real case and write down every screen the person looked at. 3. **Write the steps, one action each.** Start each step with a verb and give it one action. Microsoft’s example: do not write “extract metrics and summarize findings”; write two steps. Pro Sulum’s test is whether you can check the step in one look. Agent Process says to start a new step when responsibility changes, when a result must be recorded, when someone decides, or when the process must wait. It also warns against turning every sentence into a step. Do this today: Do this today: read each step and ask whether you could check it in one look. If not, split it. 4. **Turn every “it depends” into a rule.** Agently’s pattern is IF, THEN, ELSE IF, ELSE, with a safe default and the person to notify. Put the condition before the action, as Agent Process says, and say what to do when no rule fits. Order the rules so the first match wins. In our example: if there is no purchase order, stop and hand the case to the accounts payable lead. If every line is within 2% of the order price, mark it matched. Anything else goes to a person. Do this today: Do this today: search your draft for “appropriate”, “as needed” and “use your judgment”, and rewrite each as a rule. 5. **Write the stop conditions and the hand-off.** List what makes the agent stop: a missing input, a tool error, a case that no rule fits, a step that cannot be undone. For each, name a person or role, what the agent sends, and the status it leaves behind. OpenAI’s agent guide gives two triggers for human intervention: the agent exceeds a set limit of retries or actions, or the action is sensitive, irreversible or high-stakes, such as a payment or a large refund. Agent Process says to send missing inputs and unclear policy to a person rather than invent a success. Do this today: Do this today: for each stop condition, write the first line of the message the person will receive. 6. **Write the check.** Say what proves the work is right, in terms someone else can verify: a status, an ID, a log entry. Agently says that if you cannot fill in the verification, you do not yet have an SOP. Agent Process warns that reaching the last step is not the same as achieving the result, so check against the recipient’s need and the system of record. Our example check: the status matches the rule that fired, and the log lists every line checked. Do this today: Do this today: write the check before the steps, then see whether the steps would produce it. ## One step, before and after Here is our example step written twice. The left column is what most teams have. The right column is what an agent can run. Every gap in the left column is a guess waiting to happen. An illustration. The thresholds, roles and statuses are invented for this post, not taken from any company or source. | | SOP written for a person | SOP an agent can follow | | --- | --- | --- | | The step | Check the invoice against the purchase order. If something looks off, sort it out with the buyer. | For each line, work out the difference from the purchase order price as a percentage. If every line is within 2%, set the status to “price matched” and stop. If any line is over 2%, draft a note to the buyer that lists those lines, and set the status to “waiting for buyer”. A person sends the note. | | Trigger | Not written. The clerk knows the exception queue. | Start when the status is “price exception”. Any other status belongs to another SOP. | | What “off” means | The clerk knows it means more than a few cents. | 2% of the purchase order price, held in the reference section so finance can change it. | | Exceptions | In the clerk’s head: new suppliers go elsewhere, big invoices go to the lead. | Written as ordered rules, each with a named recipient. | | When to stop | Not written. The clerk asks someone. | Stop when an input is missing, when the total is over $10,000, or when no rule fits. Hand the case to the accounts payable lead with the invoice number. | | Proof it worked | “Make sure it is sorted.” | The status matches the rule that fired. The log lists each line, both prices and the rule number. | The right column is longer, and that is fine. Tallyfy makes the same point about a purchasing rule: rewritten for a reader with no context, it roughly triples in length. Length alone is not the aim, though. Agently notes that a forty-page document can still miss the trigger, the meaning of done, what to do when data is missing and what must never happen. It suggests that many operational SOPs fit in one to three pages when rewritten. ## A skeleton to copy, and the same SOP filled in The first block is the skeleton. Paste it into a doc and fill it from top to bottom. The second block is our invoice example, filled in, so you can see how much goes in each part. Its numbers are invented. **Template: Agent SOP skeleton** One SOP per trigger. If you need a second trigger, write a second SOP. ```text AGENT SOP: Owner (one named person): ________ Version: ____ Last changed: ________ Reviewed by someone who does this work: ________ 1. PURPOSE The agent is: The goal is: The goal is not: Why it matters: 2. TRIGGER Start when: Do not start when: One agent per case: set the status to first. If it is already set, stop. 3. INPUTS For each: name | where it comes from | format | what to do if it is missing 4. TOOLS AND ACCESS Read: Write: Nothing else may be used. 5. STEPS (one action each, in order) Step 1. Do: . Use: . Output: . Step 2. ... 6. DECISION RULES (checked in order, first match wins) Rule 1. If , then . Rule 2. If , then . Otherwise: , then tell . 7. STOP AND HAND OFF Stop when: times / step cannot be undone> Hand the case to: Send them: Leave the status as: 8. NEVER 9. OPEN ZONE (optional) The agent may use its own judgment only when ALL are true: - the action is read-only - it uses only data already retrieved for this case - it contradicts nothing above - it serves a real need of someone in this process 10. CHECK Done means: Record: If the check fails: 11. REFERENCE (the parts that change) Thresholds | contact list | message templates | tolerance table 12. TEST CASES A normal case. One case for each outcome. A case just inside and just outside every threshold. A case with a missing input. A case where a tool fails. ``` **Template: The same skeleton, filled in: supplier invoice price exception (illustration)** Invented numbers and roles. Replace every threshold and contact with your own. ```text AGENT SOP: Supplier invoice price exception (ILLUSTRATION, ALL NUMBERS INVENTED) Owner: Accounts payable lead Version: 1 1. PURPOSE The agent is: an accounts payable assistant that triages one invoice at a time. The goal is: to decide quickly whether a price difference is inside tolerance, or which person must look at it, with the evidence attached. The goal is not: to approve payment. A person releases every payment. Why it matters: a wrong payment is hard to pull back, and a late look is not. 2. TRIGGER Start when: an invoice has the status "price exception". Do not start when: the status is "no PO" or "duplicate". Those have their own SOPs. One agent per case: set the status to "agent working" first. If it already says that, stop. 3. INPUTS Invoice number, supplier ID, line prices | invoice record | read-only | if missing, Rule 2 Purchase order line prices | ERP, read-only | by invoice number | if no order is found, Rule 2 Supplier status | vendor list, read-only | if not listed, Rule 1 Tolerance | section 11 4. TOOLS AND ACCESS Read: invoice record, ERP purchase orders, vendor list. Write: the status field, and a draft note to the buyer. Nothing else may be used. 5. STEPS Step 1. Read the inputs. Use: the three read-only tools. Step 2. For each line, work out the difference from the purchase order price as a percentage. Step 3. Apply the decision rules in order. Step 4. Write the log entry (section 10). 6. DECISION RULES (first match wins) Rule 1. If the supplier is not in the vendor list, stop and hand the case to Vendor Setup. Rule 2. If any input is missing, or no purchase order matches, stop and hand the case to the accounts payable lead. Rule 3. If the invoice total is over $10,000, stop and hand the case to the accounts payable lead. Rule 4. If every line is within the tolerance, set the status to "price matched" and stop. Rule 5. If any line is over the tolerance, draft a note to the buyer that lists those lines with both prices, set the status to "waiting for buyer" and stop. Otherwise: stop and hand the case to the accounts payable lead. 7. STOP AND HAND OFF Stop when: Rules 1, 2, 3 or the final "otherwise" apply, a tool returns an error, or any step fails twice. Hand the case to: the role named in the rule. Send them: the invoice number, the rule that fired, and what is missing or over. Leave the status as: "needs a person". 8. NEVER Release or approve a payment. Change a purchase order, an invoice or the vendor list. Send the note to the buyer (a person sends it). Guess a price. 9. OPEN ZONE If the buyer asks which order the invoice was matched to, or which lines were over tolerance, answer from the data already retrieved. Read-only. Do not change the status. 10. CHECK Done means: the status matches the rule that fired. Record: invoice number, each line checked, the purchase order price, the invoice price, the percentage difference, and the rule number. If the log is incomplete: set the status to "agent error" and tell the accounts payable lead. 11. REFERENCE Tolerance: 2% of the purchase order price. Review limit: invoice total over $10,000. Contacts: accounts payable lead, Vendor Setup, the buyer named on the purchase order. 12. TEST CASES A clean match. A line at 2.1% over the order price. A supplier not in the vendor list. An invoice with no purchase order. A total of $10,000 and a total of $10,001. A tool that returns an error. ``` Notice what moved. The 2% and the $10,000 sit in section 11, so finance can change them without touching a step. AWS recommends the same split: tolerance thresholds, formulas, message templates and contact lists go in reference sections, so the steps and the agent do not change when a threshold does. Agently makes a related split between policy, which says what is allowed, and procedure, which says how to do it in the tools. ## What eight public pages tell you to include We read six pages written about SOPs and process instructions for agents: AWS Builder Center, Pro Sulum, Agently, Tallyfy, Microsoft Learn and Agent Process. We added OpenAI’s agent guide, which has a short section on instructions. We read Anthropic’s prompting guide too, but it covers prompts in general, so it is not in the grid. **What each page says to put in the SOP** (none, partly or fully) | | AWS | Pro Sulum | Agently | Tallyfy | Microsoft | Agent Process | OpenAI | | --- | --- | --- | --- | --- | --- | --- | --- | | What starts it (trigger) | partly | none | fully | none | none | fully | none | | Named inputs and outputs | partly | fully | fully | fully | partly | fully | partly | | One action per step | partly | fully | fully | fully | fully | fully | fully | | Decision rules as if, then | fully | fully | fully | partly | partly | fully | fully | | When to stop, and who gets the case | fully | fully | fully | fully | partly | fully | fully | | A check that proves it worked | partly | fully | fully | fully | partly | fully | none | | A list of what the agent must never do | fully | none | partly | none | none | partly | none | | Which steps need a person’s approval | partly | fully | partly | none | none | fully | fully | | Thresholds and policy kept apart from steps | fully | none | partly | none | none | partly | none | | Testing before trust | partly | fully | none | none | fully | fully | partly | Our reading of the pages listed under Sources, read in full on 2026-10-16. A full ball means the page asks for it clearly, a half ball means it touches on it, an empty ball means we found nothing. This scores what a page says, not how good the advice is. A page can also do more than its text shows. Anthropic’s prompting guide is not scored because it covers prompts in general. > **How we read them.** We fetched the raw text of each page and read it in full on 2026-10-16. Three of the pages come from companies that sell something nearby: Pro Sulum sells process-building services, Agently sells an AI agent, and Tallyfy sells process software. Microsoft’s page is for one product, declarative agents in Microsoft 365 Copilot, so some of its limits belong to that product. We note this so you can weigh the advice. Read down the grid. Nearly every page wants one action per step and a place to stop. Only Agently and Agent Process ask for a trigger in so many words, and AWS only implies one. Few pages tell you to keep thresholds apart from the steps, which is the habit that keeps an SOP usable after the first change in policy. Three pages, Pro Sulum, Agent Process and OpenAI, tell you to mark which steps need a person’s approval. The check row is the one we would not skip: with no proof of done, there is nothing to test against. ## How rigid should it be? The pages disagree A cook’s recipe has two kinds of line. “Heat the oven to 200 degrees” leaves no choice. “Season to taste” hands the choice to the cook. An agent SOP needs both, and the pages disagree on how much of each. Here is our reading of where they sit. **How much each page fixes in advance, and how much room it leaves the agent** (x: How much of the procedure is fixed in advance, 0 to 100; y: Room left for the agent to reason, 0 to 100; corners: top-left Loose, with reasons, top-right Locked where it matters, open elsewhere, bottom-left Loose and vague, bottom-right Fully scripted) - Anthropic (prompts): x 15, y 88 - Microsoft: x 38, y 68 - AWS: x 66, y 82 - Tallyfy: x 52, y 54 - Agent Process: x 45, y 40 - OpenAI: x 58, y 26 - Agently: x 80, y 22 - Pro Sulum: x 93, y 8 - What we would write: x 76, y 62 Our reading, not a measurement. Horizontal: how much of the procedure the page asks you to fix in advance (steps, thresholds, branches). Vertical: how much room it leaves the agent to reason inside the fixed parts. Anthropic’s page is about prompts in general and OpenAI’s about agents in general, so they are placed on what they say about instructions. ### Locked or open AWS splits an SOP into two zones. The locked zone holds formulas, approval thresholds, write sequences and prohibited actions, and the agent has no latitude there. The open zone is where the agent reasons like a skilled person, if each action is read-only, uses only data already retrieved, contradicts no locked rule and serves a legitimate interest of someone in the process. AWS warns that with no open zone the agent adds nothing beyond what code could do, and with no locked zone the results are inconsistent. Pro Sulum goes further the other way: an agent has no judgment to fall back on, so turn each judgment call into an if-then rule, and stop and escalate on anything uncovered. Anthropic’s prompting guide leans the opposite way, advising you to give the reason behind an instruction because the model can generalize from it. What we would do. Lock everything that moves money, changes a record or sets a threshold. Write the rest as a goal plus a reason, and add a small read-only open zone like the one in our template. If you find yourself locking every branch, you may not need an agent. Plain code is cheaper and steadier, and our four-bucket method is how to check. ### Say what to do, or say what to avoid AWS ends its SOP with an explicit NEVER list. Microsoft advises the opposite: focus on what the agent should do, not on what to avoid. Tallyfy sides with Microsoft and says to write rules as MUST, not MUST NOT. Tallyfy reports its own test numbers, but the page links no data, so we do not repeat them. What we would do: write rules as actions, keep a short stop list for the few things that must never happen, and test that the agent obeys the stop list. What we would do. Write every stop as a positive action: “if there is no purchase order, stop and hand the case to the accounts payable lead”. Keep a short never list as a backstop, and set the same limits in the tool’s permissions. Agently says the same about approvals: where stakes are high, build them into the system, because prompt text alone is easier to skip. AWS shows the layers it uses, from guardrails and authorization policies to the target system’s own access controls. Our harness guide explains where those controls live. ### Length Agently suggests many operational SOPs land at one to three pages and should be split by trigger. Microsoft states a hard limit of 8,000 characters for the instructions of a declarative agent, and warns against moving instructions into a shared document to get around it. What we would do: write one SOP per trigger, and treat a long rule list as a reason to test for rules the agent skips. > **The SOP is not the lock** AWS says an SOP can sit in a knowledge base that the agent reads at run time, which means an untested change to the SOP acts like an untested code change. Treat edits the way you treat releases: one owner, a version number, and a re-run of your test cases before it goes live. ## Test it in shadow mode before it touches real work Picture a trainee who does each invoice on a practice copy while the clerk does the real one. Nothing the trainee does reaches a supplier. At the end of the week you compare the two piles. Shadow mode works the same way: the agent gets the same inputs as your team, sends and changes nothing, and its output is scored against what your people did. **Draft, test, fix, repeat** 1. **Draft the SOP**: From one real run, with the people who do the work. 2. **Run on past cases**: Normal cases, each outcome, and the ugly ones. 3. **Run beside live work**: Shadow mode: nothing is sent or changed. 4. **Compare**: Score each step against its own check, not the final feel. 5. **Fix the wording**: Change the step that failed, not the whole SOP. Then loop back: Edit, then run the same cases again Our reading of the draft, test and fix loop described by Pro Sulum, Agent Process, Microsoft and our shadow mode guide. Choose the cases on purpose. Agent Process asks you to walk a normal case, each different outcome, and the failure and rework paths, with boundary values for any threshold, and to have someone other than the author run it. For our example, section 12 of the filled-in SOP lists them. The boundary cases are there to catch wording like “over” against “at or over”, which a person resolves without thinking and an agent does not. Score each step against its own check. Pro Sulum says to judge every step against its success criteria rather than the final impression, and when a step fails, to fix the wording of that step and test again. Microsoft’s loop is the same: test, then change the instructions and look at the output again. Each scored case can then be kept as a test in your eval set, so the next edit to the SOP is checked against all of them. Deciding when to remove a person from a step is a second test. Agent Process suggests starting with approvals where trust has not been earned, then adding an advisory check before the approval and comparing its verdicts with what the approvers decided on real cases. Agree in advance how many false passes and false fails you can accept. Time passing is not evidence. Pro Sulum adds the reverse: if a person approves a step nearly every time with no changes, the checkpoint is theater, and a spot check will do. Our shadow mode guide covers how an agent earns more autonomy one step at a time. ## Ten checks before you give it to an agent **Before you hand the SOP over** - [ ] Someone who did the job last week reads it and says it matches what they did, including a difficult case. - [ ] A colleague who has never done the job can say, from the text alone, what the first step is. - [ ] The trigger names an event, status or field value, and says what looks similar but does not start it. - [ ] Every input has a name, a source and a rule for when it is missing. - [ ] Every step is one action you could check in one look, and names the tool it may use. - [ ] Every “it depends” is written as an if-then rule, in order, with a safe default. - [ ] Every stop condition names a person or role, and says what the agent sends them. - [ ] Steps that move money, reach someone outside or cannot be undone are marked for a person’s approval, and the same limit is set in the tool’s permissions. - [ ] Thresholds, contacts and message templates sit in one reference section, not inside the steps. - [ ] The SOP ends with a check someone else can verify, and a list of test cases that includes cases either side of every threshold. ## Where Nolli fits, and where it does not Nolli maps how the work really runs, from your people’s work on company devices, your email and calendar, and the logs of the AI agents they use. When you ask for an SOP, it writes one from what it has learned: the observed steps, the people involved, the systems and the exceptions, with each line linked to where it came from. That covers the part people skip, which is the real run and the exceptions that someone handles from memory. It does not decide your policy. Observed work shows what people did, so your owner still confirms every threshold, every hand-off and every limit. A step Nolli never saw will not be in the draft, and an SOP is not proven until you test it, which Nolli supports with shadow mode on your own work. Your company also decides what Nolli may learn from. You can write this SOP by hand with the skeleton above. See the Equip pillar. No public price. Request a demo. ## Questions people ask **What is an SOP for an AI agent?** It is a written procedure the agent works from, with nothing left to a reader’s experience. It names the trigger, the inputs, the steps, a rule for each judgment call, the conditions where the agent stops and who gets the case, and a check that proves the result. **How is an agent SOP different from a normal SOP?** A normal SOP relies on the reader to fill in the unwritten parts, such as what “off” means, who handles the exception, and when to ask. An agent has no such background, so each of those must be written down, in order, with a named recipient for every hand-off. **How long should an SOP for an AI agent be?** Agently suggests as short as possible while keeping the branches and the check, and says many operational SOPs land at one to three pages. It also says to split by trigger, so one SOP covers one starting event. Microsoft limits declarative agent instructions to 8,000 characters. **Should I use MUST and NEVER in an SOP?** The pages differ. AWS and Tallyfy recommend RFC 2119 keywords such as MUST, SHOULD and MAY. AWS also keeps a NEVER list, while Microsoft and Tallyfy say to phrase rules as actions to take. We write stops as actions, keep a short never list, and set the same limits in permissions. **Can the SOP alone stop an agent from doing something harmful?** No. Agently says to build approvals into the system where stakes are high, because prompt text alone is easier to skip. AWS lists further layers, including guardrails, authorization policies and the target system’s own access controls. **Who should write the first draft?** Someone who did the job correctly recently. Agently says the person who last did it right beats a manager who has not used the tool in years. Agent Process asks you to ask the people who do the work how a recent normal case and a recent difficult case went. ## Sources - "How to Write Agent SOPs That Give AI Agents Space to Think." AWS Builder Center, August 11, 2026. https://builder.aws.com/content/3GVUUt2KTK3GyCmbu3pwEBYTZ1q/how-to-write-agent-sops-that-give-ai-agents-space-to-think - Dean Soto. "Write an SOP an AI Agent Can Run." Pro Sulum, July 18, 2026. https://www.prosulum.com/guides/writing-sops-ai-agents-can-run/ - Omar Ghandour. "How to Document SOPs for AI Agents." Agently, April 15, 2026 (updated August 7, 2026). https://agently.dev/blog/how-to-document-sop-for-ai - Amit Kothari. "How to write a process for an AI agent (not a human)." Tallyfy, updated August 5, 2026. https://tallyfy.com/how-to-write-a-process-for-an-ai-agent/ - "Write effective instructions for declarative agents." Microsoft Learn, accessed October 16, 2026. https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/declarative-agent-instructions - "Best practices for process authors." Agent Process, accessed October 16, 2026. https://agentprocess.io/docs/authoring/best-practices/ - "A practical guide to building agents." OpenAI, accessed October 16, 2026. https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf - "Prompting best practices." Anthropic, Claude API docs, accessed October 16, 2026. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices