From Idea to Deployed AI Agent: My Full Stack in Allen, TX

The first AI agent I shipped took me three weeks. Not because Claude was hard to call — the API is straightforward. Not because the logic was complicated. It took three weeks because I kept discovering new layers of infrastructure I hadn't thought about. Where does the data go? How does the agent get triggered? What happens when it fails? How do clients see the output?

Two years and a dozen production agents later, I have answers to all of those questions. The answers look like a specific set of tools, each doing one job, all wired together. This post is the map I wish I had when I started.

I run VIXI LLC out of Allen, TX. We build AI automation systems for marketing agencies and B2B companies — lead qualification agents, voice screeners, attribution pipelines, client reporting bots. Every one of them runs on the same underlying stack. The tools change slightly depending on the use case, but the architecture stays the same.

Let's go through each one, what it does, why I chose it, and how it connects to the others.

Claude is the reasoning layer for every agent I build. I've tested GPT-4, Gemini, and a handful of open-source models. For production work that involves long context, nuanced instruction-following, and tool use that doesn't hallucinate, Claude consistently outperforms the alternatives.

The specific capability I rely on most is tool use — Anthropic's name for structured function calling. You define a set of tools (essentially JSON Schema describing an action and its parameters), include them in the API request, and Claude will choose when to call them and with what arguments. This is how agents take real actions instead of just generating text.

Here's a minimal example of a Claude agent that can query a Supabase table:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const tools = [
  {
    name: "query_leads",
    description: "Query the leads table from Supabase",
    input_schema: {
      type: "object",
      properties: {
        status: {
          type: "string",
          enum: ["new", "contacted", "qualified", "closed"],
          description: "Filter leads by status"
        },
        limit: {
          type: "number",
          description: "Max number of results to return"
        }
      },
      required: ["status"]
    }
  }
];

const response = await client.messages.create({
  model: "claude-sonnet-4-6",
  max_tokens: 1024,
  tools,
  messages: [
    {
      role: "user",
      content: "Show me the 10 newest uncontacted leads"
    }
  ]
});

// Claude returns a tool_use block when it wants to call query_leads
if (response.stop_reason === "tool_use") {
  const toolUse = response.content.find(b => b.type === "tool_use");
  console.log("Tool called:", toolUse.name);
  console.log("Arguments:", toolUse.input);
  // → { status: "new", limit: 10 }
}

Every agent I build starts here: a system prompt defining the agent's role, a set of tools it can call, and a loop that processes tool results and continues the conversation until the task is done. The complexity comes from the infrastructure around this loop, not the loop itself.

Writing raw Claude API calls works fine for one agent. For a fleet of agents that share tools, memory, and file systems, you need a consistent runtime — a layer that handles the boilerplate so each agent only defines what's unique to it.

OpenClaw is that runtime. It's a CLI-first agent framework that wraps Claude API calls with a structured workspace model. Each agent lives in its own workspace directory with defined tool access, a persistent memory file, and a standard way to hand off results to other systems.

The workspace convention matters because it lets OpenMOSS know where to look. When a MOSS task completes, it reads the agent's workspace output directory to pick up the result. When a new task starts, it writes the task context into the workspace input directory. The agents themselves don't need to know anything about the task queue — they just read from a known location and write to a known location.

# OpenClaw workspace structure
~/.openclaw/
  workspace/
    agents/
      bella-bot/
        system-prompt.md
        tools.json
        memory/
        output/
      dev-bot/
        system-prompt.md
        tools.json
        memory/
        output/
    moss-tasks/       # task lock files + outputs
    shared/           # cross-agent shared context

# Trigger a specific agent on a task
openclaw run bella-bot --task "Qualify lead: John Smith, ACME Corp"

# Run with a specific MOSS task context
openclaw run dev-bot --moss-task f1a75d48-67a0-45ba-923e-b6633daa96fe

For agents that run on a schedule or in response to events, I wrap the OpenClaw CLI call in an n8n Execute Command node. The n8n workflow handles the trigger logic; OpenClaw handles the actual agent execution. Clean separation of concerns.

OpenMOSS is a self-hosted REST API that acts as a shared task queue for all my agents. The core insight behind it: agents running in parallel need a source of truth about what's in progress, what's done, and what needs to happen next. Without that, you get race conditions, duplicated work, and failures with no audit trail.

Every significant agent action in my stack is represented as a MOSS task. Tasks have a lifecycle: pending → running → completed (or failed). Any agent — or any external system — can create a task, claim it, update it, and mark it complete via the REST API.

# Create a new MOSS task
curl -X POST "http://localhost:6565/api/tasks" \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Qualify inbound lead: Sarah Chen",
    "agent": "bella-bot",
    "priority": "high",
    "metadata": {
      "lead_id": "lead_8823",
      "source": "website_form"
    }
  }'

# Response includes the task ID
# { "id": "abc123", "status": "pending", ... }

# Agent claims the task when it starts
curl -X PUT "http://localhost:6565/api/tasks/abc123/status" \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"status": "running"}'

# Mark complete when done
curl -X PUT "http://localhost:6565/api/tasks/abc123/status" \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"status": "completed", "result": "Lead qualified. Score: 87/100."}'

The task ID is the shared reference point across all systems. n8n creates the task and stores the ID. OpenClaw picks it up and runs the agent. Supabase logs the result with the same ID. That ID is what lets you reconstruct exactly what happened and when — without manually correlating logs from three different systems.

n8n is where external triggers meet my AI infrastructure. A new form submission, a Calendly booking, a Stripe payment, a Hyros attribution event — all of these enter the stack through n8n webhooks. From there, n8n creates MOSS tasks, triggers OpenClaw agents, updates Supabase records, and fires notifications.

The reason I use n8n instead of writing webhook handlers in code: the visual editor makes it trivial to debug, modify, and hand off to non-engineers. When a client wants to add a new trigger ("also fire the agent when a deal stage changes in HubSpot"), I add two nodes in n8n, not a new deployment.

I also maintain n8n-nodes-hyros, a custom community node for Hyros attribution that has over 4,500 installs. It's a good example of how n8n's extensibility pays off — one custom node and any Hyros event can trigger any agent in my stack.

// n8n workflow (simplified JSON representation)
// Trigger: Webhook (POST /webhook/new-lead)
// Step 1: HTTP Request → Create MOSS task
{
  "method": "POST",
  "url": "http://localhost:6565/api/tasks",
  "headers": { "Authorization": "Bearer {{ $env.MOSS_KEY }}" },
  "body": {
    "title": "Qualify: {{ $json.name }}",
    "agent": "bella-bot",
    "metadata": {
      "lead_id": "{{ $json.id }}",
      "email": "{{ $json.email }}"
    }
  }
}
// Step 2: Supabase → Insert pending lead record
// Step 3: Execute Command → openclaw run bella-bot
// Step 4: Wait for MOSS task completion (polling loop)
// Step 5: Slack notification with result

One pattern I use constantly: a polling sub-workflow in n8n that checks the MOSS task status every 30 seconds and waits for completed before proceeding. It sounds primitive but it's reliable — and because it's n8n, I can see exactly where the workflow is at any point in time.

Not every agent interaction happens in a chat interface. For my VIXI clients who qualify inbound leads over the phone, the interface is voice — and Retell is the layer that makes that work.

Retell handles the telephony complexity: inbound call routing, real-time speech-to-text, LLM response generation, and text-to-speech output — all in under 800ms latency end-to-end. Under the hood, you configure a Retell agent with a Claude model and a system prompt. Retell handles the streaming, the turn-taking, and the audio. I handle the business logic in the system prompt and the tools.

The integration with the rest of my stack works through webhooks. When a Retell call ends, it POSTs the full transcript to an n8n webhook. n8n parses the outcome ("qualified", "not interested", "left voicemail"), creates a MOSS task for any follow-up work, and writes the call log to Supabase with the MOSS task ID for traceability.

Voice changes the value proposition significantly for agency clients. Sending AI-written emails is table stakes. Picking up the phone — and doing it consistently at 2am when humans aren't available — is something different. Retell + Claude is how that works.

AI agents are stateless by default. Each conversation starts fresh. For production use, that's not acceptable — agents need to remember context across sessions, clients need their data isolated from each other, and every significant action needs a durable audit trail.

Supabase solves all three. It's PostgreSQL with a REST API, built-in auth, row-level security, and real-time subscriptions. The real-time layer is especially useful: when an agent writes a result to a table, Supabase fires an event that n8n picks up immediately — no polling required.

My core schema looks like this:

-- Core tables in my production Supabase instance

-- Agent task audit trail (synced from OpenMOSS)
create table agent_tasks (
  id uuid primary key default gen_random_uuid(),
  moss_task_id text unique not null,
  agent_name text not null,
  status text not null default 'pending',
  result jsonb,
  client_id uuid references clients(id),
  created_at timestamptz default now(),
  completed_at timestamptz
);

-- Call logs from Retell webhooks
create table call_logs (
  id uuid primary key default gen_random_uuid(),
  retell_call_id text unique not null,
  transcript text,
  outcome text,         -- 'qualified', 'not_interested', 'voicemail'
  lead_score int,
  moss_task_id text,    -- links to agent_tasks
  client_id uuid references clients(id),
  created_at timestamptz default now()
);

-- Per-client agent memory (long-term context)
create table agent_memory (
  id uuid primary key default gen_random_uuid(),
  agent_name text not null,
  client_id uuid references clients(id),
  memory_key text not null,
  memory_value jsonb not null,
  updated_at timestamptz default now(),
  unique(agent_name, client_id, memory_key)
);

Row-level security on every table means each client's data is completely isolated. A single Supabase project handles all clients because RLS policies ensure no query can return rows belonging to a different client_id. That's multi-tenancy without the infrastructure overhead of running separate databases.

Every client-facing surface in my stack — dashboards, onboarding forms, agent chat interfaces, this website — is a Next.js app deployed on Vercel. The deploy story is the best thing about Vercel: git push origin main and you're live in 60 seconds.

Beyond static deploys, I use Vercel API routes as lightweight Claude proxy endpoints. Instead of exposing my Anthropic API key to the client, the browser calls a /api/chat route on Vercel that forwards the request to Claude and streams the response back. The key stays server-side; the latency stays low because Vercel Edge runs close to users.

// app/api/chat/route.ts — Vercel Edge API route
import Anthropic from "@anthropic-ai/sdk";

export const runtime = "edge";

export async function POST(req: Request) {
  const { messages, systemPrompt } = await req.json();

  const client = new Anthropic({
    apiKey: process.env.ANTHROPIC_API_KEY,
  });

  const stream = await client.messages.stream({
    model: "claude-sonnet-4-6",
    max_tokens: 1024,
    system: systemPrompt,
    messages,
  });

  // Stream response back to the browser
  const encoder = new TextEncoder();
  const readable = new ReadableStream({
    async start(controller) {
      for await (const chunk of stream) {
        if (
          chunk.type === "content_block_delta" &&
          chunk.delta.type === "text_delta"
        ) {
          controller.enqueue(
            encoder.encode(`data: ${JSON.stringify({ text: chunk.delta.text })}

`)
          );
        }
      }
      controller.close();
    },
  });

  return new Response(readable, {
    headers: {
      "Content-Type": "text/event-stream",
      "Cache-Control": "no-cache",
    },
  });
}

Edge runtime is the right choice here because Claude streaming responses need to stay open for several seconds. Traditional serverless functions time out; Edge functions stay open as long as the stream is active.

Let me walk through a complete example: a new lead submits the contact form on a client's Vercel-hosted landing page. Here's what happens in the next 90 seconds.

Total elapsed time from form submission to a qualified lead appearing on the client dashboard: under 90 seconds on average. Without this stack, a human SDR would check the form submission hours later, make a call, and manually update a CRM. The agent does it while they sleep.

If you're building your first production AI agent, don't install all seven layers on day one. You'll spend two weeks on infrastructure and zero time on the actual agent logic. Here's the order that makes sense:

The biggest mistake I see is over-engineering the stack before you understand the problem. Start with the simplest thing that works. Add layers when you feel the pain that layer solves — not before.

I get asked sometimes why I publish this stuff — the stack details, the tool choices, the code examples. The honest answer is that I learned everything here from other people writing in public, and I think the AI agent ecosystem moves faster when practitioners share what actually works versus what they wish worked.

This stack isn't perfect. There are rough edges in every layer. But it's the stack that runs in production today, handles real client work, and has earned real money from real outcomes. That's the bar I hold it to.

If you're building something with this stack or thinking about hiring someone who runs it in production, I work with a small number of clients through VIXI. Feel free to reach out.