Agent SOP: one markdown file, three ways to install it, and a loop with no exit

The same procedure ships as three different artefacts

The format description ends with a line that is easy to skim and is in fact the distribution strategy: multi-modal distribution through MCP tools, Agent Skills and Python modules.

The repository tree is the proof. agent-sops/ holds the markdown definitions, skills/ carries the same content packaged for agent runtimes that consume skills, python/ holds the packaged Python distribution, .claude-plugin/ carries a plugin manifest, and spec/ holds the format definition. rules/ sits alongside them.

So there is one authored source and three delivery surfaces, and a user picks the one their agent can actually load. An assistant that speaks MCP gets the SOPs as discoverable prompts, an agent runtime with a skills directory gets files it can read, and a Python application imports a constant.

That last surface is the most unusual. The SOP is not a file the agent reads at runtime; it is a Python value handed to the agent constructor as its system prompt, which means the markdown and the code are compiled together at import time and a malformed SOP breaks the import rather than the run.

An SOP is imported as a constant and passed in as the system prompt

The Python example is short enough to read in full:

from strands import Agent
from strands_tools import editor, shell
from strands_agents_sops import code_assist

agent = Agent(
  system_prompt=code_assist,
  tools=[editor, shell]
)

agent("Start code-assist sop")

while(True):
  agent(input("\nInput: "))

Three things follow from those lines. The SOP arrives as the entire system prompt rather than as an appended instruction, so an agent configured this way has nothing else in its system context unless the constant itself says so. The toolset is two tools, an editor and a shell, which is the minimum a coding SOP needs and also the whole authority you are granting.

And the loop has no exit condition. It is an infinite while with a blocking input call, so the only ways out are an exception or an interrupt, and no goodbye path is shown.

The first turn is worth noting as well: the starter phrase is Start code-assist sop, which tells the agent to begin by loading the procedure rather than by doing a task. The SOP drives the session; the user supplies the work.

The artifact directory is organised by what you should commit

Four SOPs in the family write to a .agents directory, and the layout is justified by version-control policy rather than by topic.

summary/ holds the output of codebase analysis and is recommended for always committing, on the grounds that it is useful to humans and agents alike. planning/ holds the design documents from prompt-driven development, and is described as often worth committing because it captures decisions, alternatives considered and rationale that tend to be lost otherwise. tasks/ holds generated code tasks and may be committed or tracked in an issue tracker instead. scratchpad/ holds working notes from code assistance, is described as transient implementation artefacts, and is the one directory the documentation tells you to add to .gitignore.

That last recommendation is the load-bearing instruction, and it only makes sense because the other three are committed by default.

Auto-generated project names carry a date prefix in YYYY-MM-DD form for sorting, with an example like 2026-01-30-auth-system. The practical effect is that the directory listing sorts chronologically and two runs of the same project name never collide inside one checkout.

The structure also exists to make context pinning possible, which the README illustrates with a single Kiro command that adds every markdown file under a planning project as pinned context.

Five procedures, and one of them measures the others

The catalogue is a table of five.

codebase-summary analyses a codebase and generates documentation, aimed at project onboarding, documentation creation and understanding a system. pdd is the prompt-driven development methodology for complex problem solving, architectural decisions and system design. code-task-generator breaks requirements down into tasks, for planning, sprint preparation and requirement analysis. code-assist implements code with a test-driven workflow, for features, bugs and refactoring.

The fifth is different in kind. eval is an automated evaluation workflow for agents, built on the separate Strands Evals SDK, and its stated scope covers evaluation planning, test data generation, evaluation execution and result analysis, with a usage guide.

So four of the five produce something a person consumes, and the fifth consumes those outputs and scores them. That is an unusual shape for a workflow collection, and it is also the most useful thing here: the project ships a way to check whether its own procedures improved anything.

The naming follows the same logic throughout. A family of related procedures shares a verb and a suffix rather than a category, which makes them easy to list and easy to extend.

The procedures install from Homebrew, the runtime installs from pip

The install story has an asymmetry worth noticing, because the two halves of the system do not live in the same place.

The SOP collection is available twice, as a Homebrew formula and as a PyPI package:

# Using Homebrew
brew install strands-agents-sops

# Or using pip
pip install strands-agents-sops

The runtime that consumes them is pip only. The second install section is for using the SOPs with Strands agents, and it gives brew install strands-agents-sops again, followed by pip install strands-agents strands-agents-tools, and then a note that points back up to the Quick Start section for the pip alternative to the command it has just repeated.

That is a small editorial tangle, but it also documents the real asymmetry: the SOP package is largely markdown, so it can be a Homebrew formula, while the agent runtime is ordinary Python.

The practical consequence for a new user is that two of the three commands in the sequence come from different package ecosystems, and the section that introduces them repeats the first one instead of linking to it.

The documentation reaches for Kiro while the project ships its own client

The MCP section is the clearest description of how these procedures are consumed at runtime.

The server exposes SOPs as prompts that AI assistants can discover and use on demand. The command is strands-agents-sops mcp, and extra procedures can be loaded from custom directories with a colon-separated --sop-paths argument, where anything in the path has to carry the .sop.md postfix to be recognised. The documentation notes that some MCP clients will start the command for you from their own configuration rather than from a terminal.

The example given is Kiro, where you would add strands-agents-sops mcp to the file at ~/.kiro/settings/mcp.json and let the client launch it. The context-pinning example earlier is a Kiro command too.

That is a slightly odd default for a project whose own organisation publishes the Strands Python SDK, a tools repository, samples, an MCP server and an agent builder, all linked from the header of the same README. The Kiro examples are still the only complete end-to-end configuration shown, which makes them worth reading even if you use something else, because they show what a working client configuration looks like.

Two of the four code blocks stop mid-sentence

The format is defined by example, and the example is cut short.

The markdown block that shows the SOP structure opens with a title, an overview describing a structured Explore, Plan, Code, Commit workflow, a parameters section with a required task description and an optional mode that is either interactive or full self-coding, and the start of a setup step with its first two constraints. It then ends inside the second constraint, after the words You MUST discover existing instructio.

The MCP command block ends the same way, stopping on a comment that begins External SOPs ov.

What survives of the format is still enough to reconstruct it: RFC 2119 keywords do the enforcing, with MUST, SHOULD and MAY attached to individual steps, and the sections are overview, parameters, steps, then examples and troubleshooting. A constraint that says MUST is a promise about behaviour, and the format gives an agent no way to escalate when a MUST cannot be satisfied.

For a project whose entire purpose is making agent behaviour predictable, the parts that would show a failure are the parts that stop, which is worth knowing before you rely on the examples as a template.

Editorial conclusion

Agent SOP is worth borrowing the shape of even if you never install it, because the constraint vocabulary and the commit policy are the parts that make an agent workflow survive contact with a team. Installing is straightforward for the SOP package itself, less so for the runtime, since only the markdown half is on Homebrew. If you adopt one, start with the evaluation SOP rather than the implementation ones, keep the scratchpad out of version control as instructed, and check which of the three distribution surfaces your client actually supports.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. strands-agents/agent-sop on GitHub