What "Autonomous" Actually Means for a Solo Developer
A lot of writing about "AI agents" assumes you have a full Python backend team and a custom orchestration framework. As a student building side projects and internship automations, I don't have that luxury — and honestly, I don't need it. Most useful "autonomous" behavior can be built with a visual workflow tool like n8n, a well-designed system prompt, and — increasingly — MCP (Model Context Protocol) servers that expose tools to an LLM in a standardized way.
This post walks through how I actually think about building multi-step, semi-autonomous AI workflows, using patterns from two real projects: the automation work I do professionally, and the Agentic AI / MCP layer in my Elevate Fitness app.
The Core Idea: Plan → Tool Call → Decide → Repeat
Strip away the framework jargon and an "agent" is just a loop:
1. Receive a goal or user input
2. LLM decides: "do I have enough information, or do I need a tool?"
3. If a tool is needed: call it (search, database read, API call, calculation)
4. Feed the tool's result back into the LLM's context
5. Repeat until the LLM decides it has a final answer
6. Return the final answer / take the final action
You can implement this loop in a lot of ways. I've done it two ways: as an n8n workflow with conditional nodes, and as a Next.js app that calls an MCP server for structured tool access.
Building the Loop in n8n
n8n is genuinely underrated for this. Instead of writing agent-orchestration code from scratch, you can model the loop visually:
Chat Trigger
↓
LLM Node (with system prompt defining available "tools" as described actions)
↓
Switch Node (routes based on LLM's decided action: "search", "calculate", "respond")
↓
[Search Branch] → HTTP Request Node → back to LLM Node with results
[Calculate Branch] → Function Node → back to LLM Node with results
[Respond Branch] → Respond to Chat Trigger
The system prompt is doing most of the heavy lifting here. A simplified version of the kind of prompt I use to make an LLM node behave like a decision-making step:
You are a workflow controller. Given the user's request and any tool results so far,
respond with STRICT JSON in this shape:
{
"action": "search" | "calculate" | "respond",
"action_input": "<string input for the chosen action>",
"final_answer": "<only present if action is respond>"
}
Rules:
- Only choose "respond" once you have enough information to fully answer.
- Never invent data you don't have — use "search" or "calculate" instead.
This turns an LLM call node in n8n into a routing decision, and the Switch node reads the action field to decide which branch to take next. It's a lightweight, no-framework way to get agentic, multi-step behavior.
MCP Servers: Giving the LLM Structured Tools
The other half of the story is MCP (Model Context Protocol). Instead of writing bespoke HTTP-calling logic every time an LLM needs to "do something," MCP standardizes how a model discovers and calls tools — things like "get exercise data," "calculate a BMI," or "fetch a user's saved workout plan."
In my Elevate Fitness project (Next.js, Supabase, ShadCN, Tailwind CSS), the Agentic AI layer uses MCP servers so the LLM generating personalized workout and diet plans can reach into structured application data — user profile fields, exercise metadata for the interactive SVG demos, and calorie/BMI calculation logic — rather than trying to reason about all of it from a single giant prompt.
A simplified shape of an MCP tool definition looks like this:
// mcp-tools/calculateBmi.ts
export const calculateBmiTool = {
name: "calculate_bmi",
description: "Calculate BMI given height (cm) and weight (kg)",
inputSchema: {
type: "object",
properties: {
heightCm: { type: "number" },
weightKg: { type: "number" },
},
required: ["heightCm", "weightKg"],
},
handler: async ({ heightCm, weightKg }: { heightCm: number; weightKg: number }) => {
const heightM = heightCm / 100;
const bmi = weightKg / (heightM * heightM);
return { bmi: Math.round(bmi * 10) / 10 };
},
};
The LLM never has to "calculate" the BMI itself (which LLMs are notoriously unreliable at) — it just recognizes when the user's request needs that tool, calls it through the MCP interface, and reasons over the structured result. That's the real value of MCP for a project like this: it separates "the LLM's job" (understanding intent, generating personalized text) from "the tool's job" (deterministic calculation, structured data lookups).
Wiring It into a Next.js App
On the frontend side, the pattern is straightforward: the Next.js app sends the user's request to a route handler, which talks to the LLM with the MCP tool definitions available, loops through any tool calls, and streams the final personalized response back to the UI.
// app/api/plan/route.ts
export async function POST(req: Request) {
const { goal, profile } = await req.json();
const result = await runAgentLoop({
systemPrompt: PLAN_GENERATION_PROMPT,
tools: [calculateBmiTool, getExerciseDataTool, getWorkoutHistoryTool],
userMessage: JSON.stringify({ goal, profile }),
});
return Response.json({ plan: result.finalAnswer });
}
Lessons Learned Building This
- Keep the loop shallow. Two or three tool calls is usually enough for a real user-facing feature. Deep agent loops are slow and expensive without adding much value for most use cases.
- Force structured output. Asking the LLM to reply in a strict JSON action shape is what makes the "autonomous" routing reliable — free-text responses are much harder to route programmatically.
- Separate reasoning from computation. Anything involving math, lookups, or deterministic logic belongs in a tool (MCP tool or n8n Function node), not in the LLM's own reasoning.
- n8n is a legitimate way to prototype agent behavior before (or instead of) writing custom orchestration code.
Want to Build Something Like This?
If you're exploring agentic AI workflows, n8n automation, or MCP-based tool integration for your own product, I'd be happy to talk through the approach. Reach out at rishabnishad22@gmail.com or on WhatsApp, or see more of my work at rishab-nishad.vercel.app.