Mārga is a six-agent MCP system that reads a one-line business goal, works out which licenses apply, and sequences the approval process, including which steps can run in parallel. It's built on the NitroStack SDK and deployed through NitroCloud.
What this enables
- Turns a one-line business goal into a specific list of required licenses and departments
- Separates deterministic regulatory lookups from the conversational layer that plans the workflow
- Identifies which approval steps can run in parallel instead of strictly sequentially
- Exposes application submission, fee payment, and inspection scheduling as callable MCP tools
- Replaces six unrelated department websites with one sequenced workflow graph
Six departments, zero coordination
Starting a small business routinely means dealing with more than one licensing authority at once: a trade license from the local municipal body, GST registration, and, for anything involving food, an FSSAI certificate, each with its own forms, fees, and processing time. None of these departments coordinate with each other, and the dependencies between them, which application has to be filed before which, aren't published anywhere as a single checklist.
Mārga is a hackathon-built platform that treats this as a workflow orchestration problem rather than a search problem. An entrepreneur describes what they want to do in plain language, the example the project ships with is "I want to start a bakery in Kochi", and six specialized agents take it from there, from identifying applicable regulations to generating and optimizing an approval sequence.
Why sequencing is harder than it looks
The project's stated problem isn't just that licenses are hard to find, it's that the dependencies between them are non-obvious and manual planning is slow. That second point matters more than it sounds. Two licenses that could be applied for in parallel often get filed sequentially by default, simply because there's no tool showing which steps don't actually block each other.
That sequencing question is also where a chatbot alone falls short. Knowing that a bakery in Kerala needs a trade license, GST registration, and an FSSAI certificate is a lookup. Knowing that the trade license and GST application can proceed in parallel while the FSSAI inspection can only be scheduled once the premises are registered is a dependency graph problem, and it has to stay correct as the business type and state change. A static FAQ page can't do that. A workflow engine that treats each license as a node with explicit dependencies can.
Why MCP is the right boundary here
Mārga's MCP Execution Agent doesn't just read regulations, it acts on them. The project's MCP layer exposes application submission, fee payment, inspection scheduling, and workflow tracking as typed tools rather than as instructions the model has to paraphrase into a browser action. That boundary is what turns a "here's what you need to do" chatbot into a system that can execute a step in the approval chain and report back whether it succeeded, the difference between advice and automation in a regulatory workflow.
Six agents, one workflow graph
The system is organized as six agents that hand off to each other in a fixed sequence:
- A Goal Planning Agent parses the plain-language business description and extracts the objective: business type, location, and applicant status.
- A Knowledge Agent queries a set of structured JSON stores, covering licenses, fees, dependency rules, document requirements, processing times, and department mappings, to pull what applies to that business type and state.
- A Workflow Agent turns that flat list into a dependency-aware graph: which approvals block which, and in what order they're required.
- An Optimization Agent walks that graph looking for steps with no shared dependency, so they can be scheduled in parallel instead of one after another.
- An MCP Execution Agent carries out the supported actions, submitting applications, scheduling inspections, initiating fee payments, through MCP tools rather than describing the steps to the user.
- A Recommendation Agent watches the resulting plan for bottlenecks and suggests the next action once a step completes.
Where NitroStack fits
The six agents are built as MCP tools using the NitroStack SDK, which gives the project schema-bound tool definitions instead of loosely structured function calls, useful when a single mis-typed field, a wrong department code, a malformed fee amount, could mean a submitted application gets rejected. The MCP Execution Agent's actions are each defined as separate tools rather than one large "do the government thing" function, which keeps the audit trail readable: it's possible to see exactly which action ran, with what input, at which step of the plan. The project is deployed through NitroCloud, so the MCP server the agents rely on runs as a hosted endpoint rather than something the team has to keep alive on a laptop during a demo.
What the plan demonstrates
In a demo run for a bakery in Kochi, the pipeline generated a plan with an estimated cost around ₹2,500 and a projected 22-day timeline against a 27-day sequential baseline, a five-day reduction produced by identifying two tracks of approvals that could run in parallel rather than by skipping any step. The plan's three required approvals, trade license, GST registration, and an FSSAI certificate, matched what a manual research pass would eventually surface, but arrived pre-sequenced.
That demonstrates the dependency-graph optimization works on a realistic case, not that Mārga has processed a real application for a real bakery. The plan's accuracy is bounded by what's in its JSON knowledge base: license rules, fees, and processing windows for a given state and business category. Extending it to a new state or industry is a data-entry problem, not a rebuild of the agent logic, a deliberate trade-off that keeps the reasoning layer simple at the cost of needing the underlying regulatory data kept current by hand.
The reusable pattern
The pattern worth borrowing here isn't "AI agents for government paperwork." It's the separation between a dependency graph, deterministic, testable, sitting in ordinary data files, and a language model that interprets intent and narrates progress. The optimization step, finding which approvals can run in parallel, is graph traversal, not generation, and keeping it that way is what makes a 22-day plan a plan you can trust instead of a guess dressed up as one.
If you want to see Mārga in action, check out the complete video here:
It walks through the six-agent MCP pipeline, how the workflow handles a real business-licensing scenario, and how the Optimization Agent identifies which approval steps can run in parallel instead of sequentially.
To explore the implementation in more detail, head over to the NitroStack docs for guides on building tools, resources, prompts, testing MCP servers in NitroStudio, and deploying them through NitroCloud.
Check out the complete code over here. You can also read the source and build your own MCP application using the same SDK and workflow at nitrostack.ai.