AI Initiative logoAI Initiative
Reading room / Manthan

Manthan — Operating Principles

Defines exploration before action, noise as raw material, system independence, bounded cost, observability and unresolved questions about selection and agent lifetimes.

Project explanation / technical method
This is the retained source text, not a new validation of its claims. Numerical results and comparative claims require the accompanying source review before public reuse.

Read the connected case study or article →

Not explicitly stated in source · Date not established

Provenance, authorship and editorial notes

Manthan — Operating Principles

Id

manthan-docs-principles

Project

Manthan

Source path

manthan/docs/PRINCIPLES.md

Source sha256

9811da880c5c15d9e8ac592eaf5bd6d3dfa21b651f99a1e31b4fe826b833b3a6

Local copy sha256

9811da880c5c15d9e8ac592eaf5bd6d3dfa21b651f99a1e31b4fe826b833b3a6

Repo head

3a94084024a3434cef331fecac91c2c3b43f0313

Date
Not recorded
Date basis

Original publication date not established; Git revision date retained separately.

Author

Not explicitly stated in source

Author basis

Unknown; Git committer not substituted for document author.

Last source commit

d0ae20170b4edc4c72854c292225a138601e0423

Last source commit date

2026-05-05T08:53:56Z

Document status

Project explanation / technical method

Summary

Defines exploration before action, noise as raw material, system independence, bounded cost, observability and unresolved questions about selection and agent lifetimes.

Topics
  • Exploration architecture and selection
  • 1. Exploration, not action
  • 2. Noise is the substrate, not the enemy
  • 3. Totally independent
Theme

Exploration architecture and selection

Priority

core

Related ids
  • manthan-readme
  • manthan-docs-architecture
  • manthan-docs-business-overview
  • manthan-docs-demo-walkthrough
  • manthan-docs-qd-measurement-direction-plan
  • manthan-docs-swarm-evolution-integration
Evidence concerns
  • Recovered source text is preserved verbatim. Assertions, comparisons, commands and results belong to its original context; they were not re-executed or externally re-verified during this corpus review.
  • Earlier read-only-outward/NATS/signing descriptions differ from inspected current product paths; compare MANTHAN-REVIEW.json before describing integration as complete.
Word count

752

Bytes

4818

Source relative

docs/PRINCIPLES.md

Remote mirror

manthan/docs/PRINCIPLES.md

Full text preserved

True

Manthan — Operating Principles

These principles are the platform. The design exists to honour them, not the other way around.


1. Exploration, not action

Manthan agents are always-on, autonomous, generative. They debate, prototype, critique, synthesise.

They do not ship to production. Action belongs to Conduir / Symposium / human operators. Manthan generates the options those systems then act on.

This is the cleanest line in the architecture. Anything that would let a Manthan agent reach into a production surface — file a real PR, run a real deploy, post to a real customer channel — violates this principle.


2. Noise is the substrate, not the enemy

We do not design rigid promotion gates / cull rules upfront. The process to extract signal from noise is itself an evolving research output of the platform — not a precondition.

"I am happy with noise, we will find the process to find information from noise. What is mess vs. organized disorder... let's start and then we will review and innovate and evolve."

The name is the principle. Samudra Manthan — gods and demons churn the ocean of milk together. Halahala (poison) surfaces first; then the 14 ratnas (gems); finally amrita (the nectar of immortality). Bad ideas come early. The rare breakthrough comes late. You keep churning. Adversarial and cooperative agents both contribute to the churn.

Pre-built gates encode current assumptions about what "good" looks like. Manthan's job is to surface where those assumptions are wrong. The cull function is itself an evolving artefact — discovered by running, not specified upfront.

When tempted to pre-specify "the right cull rate" or "the right promotion gate" — resist. Ship raw and iterate.

The 1000-ideas → 200-prototypes → 1-2-opportunities ratio is a retrospective observation, not a throughput target. Actual ratios will emerge.


3. Totally independent

Manthan is its own system. Own repo (manthan/), own infra (Postgres, NATS, services), own docker-compose stack. No runtime dependency on maestro-platform.

The maestro-platform swarm builds Manthan. That is the only direction the dependency runs. Manthan agents do not import from maestro-platform; Manthan services do not call maestro-platform endpoints.


4. Read-only outward

External systems read Manthan via a stable public API: /ideas/search, /prototypes/list, /opportunities/current. They do not write into it.

A future v2 may add a feedback channel where downstream outcomes ("this idea was used in mission M, success/cost/latency = ...") flow back as fitness signal. Until then, the boundary is one-way.


5. Honest expectations

The platform's value proposition is honest: reduce the cost of generating raw material; do not pretend to reduce the cost of judgment.


6. Bounded cost from day 0

Always-on token spend is the failure mode that quietly kills always-on agent platforms. Hard limits live in code, not in plans:

Defaults shipped in .env.example; tighten in dev, loosen with eyes open.


7. Observable, even messy

We are happy with noise if it is observable noise. The viewer must let a human watch the commune live and see why an agent said what it said. Structured JSON logs from day 0; metrics endpoint per service; lineage on every artefact.

If the swarm goes off the rails, we want to be able to see it happening, not learn about it from the bill.


Tensions these principles deliberately leave unresolved

These are features of the design, not gaps. Resolving them too early is the failure mode.

Continue exploring