3. Add an outbound evaluation feed to Tazama

Previously, we already have created new rules for Tazama. But what about extending the system?

Tazama already scores transactions. What it does not hand you is a simple way for another system to see those finished evaluations.

Case Management is the product UI for investigators. It is a poor integration point for a downstream service that only wants the typology result. The result is already published. The work is finding the NATS subject that carries every finished evaluation, and subscribing to it, without adding a rule or a typology.

That subject is easy to miss. The Typology Processor also publishes on an interdiction path, and only when a score crosses the interdiction threshold. Diagrams and relay configuration often describe that path as the processor's output. An agent that follows the diagram builds a feed, connects it, and then watches it stay empty on an ordinary transaction.

That's not the hardest modification to the system, yet still requires some research before implementation. Fortunately enough, Nextdocs have got you covered in here.

Just prompt it

As simple as it seems, Nextdocs would provide you with code search capabilities that should be enough to modify Tazama without spending millions of tokens on researching the whole repo.

You can create a Nextdocs page with specification and requirements for the new service you want to do, and most of the time that's how you should do it for having consistent codebase.

However, since you have code repositories for Tazama in the Nextdocs already, you can use them to simplify the scaffolding and reducing the overall amount of tokens spent on session bootstraping:

Use Nextdocs MCP. Find the code that publishes a finished typology result, and the subject for the typology on the active network map.

Write a small Python service that:

• subscribes to that one subject on the stack's NATS server;

• keeps the last 20 messages in memory;

• serves them from GET /evaluations.

In the README, name the subject, why it is that subject, and which nearby subjects you refused.

Do not add a rule. Do not add a typology. Do not edit the running services.

The publish in typology-processor now would follow the following flow:

flowchart LR
  Rules[Rule results return] --> TP[Typology Processor]
  TP --> Subject["typology-{networkMapRules.cfg}"]
  TP --> Interdiction["INTERDICTION_PRODUCER, only past the interdiction threshold"]
  Subject --> Feed[Outbound evaluation feed]

What goes next?

Deploy the service, review the code, add the new service to Nextdocs in order to have codebase registered for future interactions.

Also you can ask the Agent to update the documents in the Nextdocs using the MCP to create or edit pages. With this, you won't need to do this manually by yourself.

Now, after following these small tutorials, you should be able to use Nextdocs to save up your token costs on code search and simplify agentic workflows. Whilst demonstrateed scenaros won't cover an ounce of possible scenarios to use Nextdocs, we believe they could be a good start to create interactions that would fit into your habits and requirements.