Write the missing manual for your on-chain agent

Could a teammate rebuild your agent stack using nothing but what you have written down? Right now the honest answer is probably no. Over the last five days you assembled something genuinely sophisticated: an agent loop that reads balances, a transfer tool, an MCP server that shares those tools, a deny-by-default policy engine, and yesterday a fully autonomous run where the whole system pursued a goal on its own. But every design decision that makes it work lives in one place only: your head. Today you get it out of your head and onto the page.

The scenario

You already know this ritual from Web2. Every mature engineering team keeps runbooks for its services, architecture docs for its systems, and README files for its repos, because code tells you what a system does but rarely why it does it that way. The engineer who wrote the service leaves, the doc stays, and the next person on call at 2am is grateful.

Agentic systems raise the stakes on this habit. A REST API behaves the same way every time you call it, so its code is almost self-documenting. Your agent does not: you watched it yesterday take different tool-call paths on different runs toward the same goal. That means the most important facts about your system, such as which invariants hold no matter what the model decides, are exactly the facts that reading a single run log will never reveal. They have to be written down deliberately. Today is a Document day, so the deliverable is a published post on DEV Community that explains your agentic stack well enough for another developer to understand it, trust it, and rebuild it.

The challenge

What you’ll need

• Your Arc 14 project folder, containing the agent loop, tools, MCP server, and policy engine from Days 92 through 96
• The run logs you saved from yesterday’s autonomous experiment (or ten minutes to re-run it and capture fresh ones)
• A text editor for drafting in Markdown
• A free account on DEV

Steps

1. Take inventory. Open your project and list every moving part. For each one, note the file it lives in, the day you built it, and its single-sentence job description. You should end up with roughly five entries: the agent loop, the balance tool, the transfer tool, the MCP server, and the policy engine. This list is the skeleton of your post.
2. Draw the flow. Sketch how a request travels through the system, from the plain-English goal down to a confirmed devnet transaction. A plain-text diagram inside a code block works well on dev.to and never breaks. Here is a starting shape; adjust the boxes and arrows until they match what your code actually does:

your goal, in plain English
        |
        v
+---------------------+
|  agent loop (LLM)   |  decides which tool to call next
+---------------------+
        |
        v  tool call, e.g. transfer_sol
+---------------------+
|  MCP server         |  exposes your tools to any client
+---------------------+
        |
        v
+---------------------+
|  policy engine      |  deny by default; every spend checked
+---------------------+
        |  allowed
        v
+---------------------+
|  Solana devnet      |  transaction submitted and confirmed
+---------------------+

3. Write the tool reference. For each tool, document its contract: the name the model sees, the inputs it accepts, what it returns, and, most importantly, whether it can move funds. A short template keeps you honest:

### Tool: transfer_sol

- **Inputs:** recipient address (string), amount in SOL (number)
- **Returns:** transaction signature, or a policy denial message
- **Side effects:** spends SOL from the agent wallet
- **Guarded by policy:** yes (see Policy section)

4. Document the policy layer. This is the heart of the post, because it is the part that makes the system safe. Write down every rule in your policy engine, what the default is when no rule matches (deny), and what a denial actually looks like from the model’s point of view. State the core invariant explicitly: the prompt can change, the model can change, the tool-call sequence can change, but no transaction moves funds without passing this layer.

5. Annotate a real run. Paste one log from yesterday’s experiment: the goal you gave, each tool call the model made, each policy decision, and the final outcome. Add a one-line comment after each step explaining what happened and why. If you captured a hostile run where the policy denied a request, include that one too. A denial log is the most convincing evidence your guardrails work.

6. Record lessons learned. Close with three to five honest observations from the week. What surprised you about non-determinism? Where did the model do something you did not predict? What would you harden before letting this touch anything beyond devnet? Open questions count as documentation too; they tell the next reader where the edges are.

7. Publish. Assemble the sections into one post on dev.to, add a title that says what you built, and tag it. The DEV Editor Guide covers the Markdown flavor, including how code blocks and cover images work. Read it once through as a stranger before you hit publish: would someone who has never seen your repo understand the diagram?

What just happened

You just produced the artifact that turns a personal experiment into an engineering system. In your Web2 life you have almost certainly benefited from someone else’s runbook or architecture doc; today you wrote one for a system where documentation carries extra weight. Because a language model’s behavior varies from run to run, the code alone cannot tell a reader what is guaranteed. Your post can, and does: it separates the parts of your stack that vary (the model’s reasoning and tool-call order) from the part that never varies (the deny-by-default policy standing between the agent and the wallet).

Notice what the writing process itself did. Forcing every tool into a contract template probably surfaced at least one fuzzy spot, maybe an input you never validated or a return value you never standardized. That is normal, and it is one of documentation’s quiet superpowers: explaining a system rigorously is one of the best ways to find its soft edges. If you felt the pull to organize your sections into “how it works” versus “how to use it,” you were rediscovering a real distinction; the Diátaxis framework formalizes it into four documentation types and is worth bookmarking for every project you build from here on.

Resources

• Model Context Protocol documentation, the protocol behind the server you documented today
• Diátaxis, a systematic framework for structuring technical documentation
• DEV Editor Guide, the Markdown and embed reference for publishing on dev.to

Submission

Publish your write-up as a post on DEV and include the hashtag #100DaysOfSolana so the rest of the challenge community can find it and learn from your stack.