2. Create a Tazama rule from a Nextdocs page

Adding a Tazama rule looks like a coding task. The expensive part is everything the code does not contain.

A rule is a contract spread across a rule document, a typology, a processor identity, and the network map. The band numbers are easy to copy from a nearby example and get wrong. Rule Studio's deploy button updates a status and sends a notification. It does not post the document the pipeline executes. If that contract lives in a chat, the next agent session invents it again. If it lives on a Nextdocs page, every agent scaffolds the same files.

Thus, the difference in using AI agent as is vs using Nextdocs MCP approximately looks like this:

flowchart TD
  subgraph repo [Agent without Nextdocs]
    direction TB
    R1[Read the seed for an existing rule] --> R2[Copy a nearby band number]
    R2 --> R3[Guess the message type from the task wording]
    R3 --> R4[Leave weights and subjects blank]
    R4 --> R5[A scaffold you cannot promote]
  end
  subgraph page [Agent with Nextdocs MCP]
    direction TB
    P1[Read the contract page] --> P2[Write rule.json and typology.json from that JSON]
    P2 --> P3[Write the processor subjects and the map notes]
    P3 --> P4[Files a reviewer can diff]
  end

The page does not replace the repositories. It is the decision, written once, that the agent is no longer allowed to renegotiate.

1. Write the contract before you ask for code

Create a page in a Nextdocs project your agents can read. One page per rule. Prose for the behavior. One JSON object for every value that must not drift.

We have already drafted a simple rule 904 specification for this tutorial, you can use it if you don't have anything on your mind for now.

As an example, for a rule that counts distinct creditor accounts paid by the same debtor in 24 hours, the object needs at least:

• the rule id and cfg, for example [email protected]

• maxQueryRange of 86400000

• an exit when the incoming transaction is unsuccessful

• band .01 with upperLimit: 3 for "fewer than three", and band .02 with lowerLimit: 3

• a new typology cfg, so the typology already on the network map stays as it is

• numeric weights, an alert threshold, and the flow processor already on that map

• RULE_NAME, RULE_VERSION, and the subjects sub-rule-<name>@<version> and pub-rule-<name>@<version>

• the network-map message the live map already uses, and {"reloadMode":"cascade"} for activation

2. Ask the agent to scaffold, and to stop there

Name the project and the page. A prompt that only says "use Nextdocs if it is connected" is how a session searches the code project, decides the docs are empty, and reconstructs the rule from a seed.

Read the Nextdocs page <page> in project <project>, "Rule 904 — creditor fan-out". That page is the contract.

Write rule.json, typology.json, processor.env, network-map.md, and accept.md.

rule.json is the rule object. typology.json is the typology object. processor.env sets RULE_NAME, RULE_VERSION, and FUNCTION_NAME, and comments the subscribe and publish subjects. network-map.md names the message, the typology you are adding, the typology you are leaving in place, and the activate body. accept.md lists how to tell the rule worked and how to roll it back.

Where the page states a value, that value wins over seed files and over rule 901's band numbers.

Do not post anything to Admin Service. Do not edit the database. Do not restart containers.

By using the following prompt, we try to set up a flow that looks approximately like this for an agent:

flowchart LR
  A[Read the page] --> B[Write the five files]
  B --> C[Diff the JSON]
  C --> D[Someone else promotes]

Actually we can omit the last sentence in the prompt to allow the AI agent automatically promote the rule after creating it. However, it's not the most transparent way to work with coding Agents, as well is not very reliable - for example, Tazama rule editor doesn't allow you to deploy the rule without testing it in a sandbox. AI agent can promote the rules without such guardrails. So make sure to either note that somewhere in the Nextdocs documents or your Agents.md.

3. Review the files against the specification

At this step, we would recommend manually checking everything to ensure agent haven't messed up the requirements and there are no problems in the code.

Then, and only then, promote: post the rule, post the typology, clone the active network map, add the new typology beside the existing one, activate, and run a processor whose exported RULE_ID matches RULE_NAME. Relabeling another rule's image exits on startup. Until that container is up, a correct map still receives nothing on pub-rule-<id>.

Promoting rules is a typical tazama workflow, so you can find more details in the Tazama documentation, or let AI agent and Nextdocs MCP do that.

Why use Nextdocs here?

If you think that AI agent can do the same without our MCP, you are correct. However, we would show our comparison.

We gave the tutorial prompt to the codex agent several times inside sandboxed environments with and without Nextdocs MCP. The model we used was gpt-6-luna:

The connected sessions produced the same rule.json, the same typology.json, and the same processor.env. Their network map notes differed in wording and agreed on the facts.

The sessions without Nextdocs MCP were more expensive on average. They spent around 380,000 input tokens on the repository scaffolding, guessed an id and a flow processor from local conventions of existing rules. However, these runs most of the time haven't managed to finish the rules properly, leaving most of the work as TODO or not following the specification provided.

Use the rules

And now that you have a new rule, you can start using it for new typologies, or modify the old ones. Using Nextdocs for such tasks simplifies the workflow and provides unified interface to collaborate for your whole team and agents without depending on each session, hoping that consistency wouldn't drift apart next time.