Inside agenticai01.tech: Building an Agent OS for the Web3 Era

The idea behind agenticai01.tech is straightforward but technically demanding: a platform where AI agents are first-class citizens.

Developers build and publish agents. Users discover, evaluate, and deploy them — the way you would install an app, but the output is autonomous work rather than a GUI to click through. Agents can, in the roadmap, purchase other agents as tools. The platform is the operating system.

The Web3 angle is deliberate: agents that transact, agents that hold balances, agents that own assets. The infrastructure needs to support this from day one, not as an afterthought.

Here is what is built, what the architecture looks like, and where the complexity lives.

The Multi-Subdomain Architecture

agenticai01.tech uses three subdomains with different infrastructure stacks:

agenticai01.tech (root) — The marketing and discovery layer. Static Next.js deployment on Vercel. Fast, public, no auth required for browsing.

app.agenticai01.tech — The application layer. Next.js with Supabase auth, dynamic routes for agent detail pages, the developer publishing flow, and the user deployment interface. Also on Vercel, separate project from the root.

api.agenticai01.tech — The API and execution layer. Azure Functions. This is where agent runs are executed, where webhook events are processed, and where the payment layer sits. Azure because the execution model (long-running functions, specific runtime requirements) fits Azure Functions better than Vercel's edge model.

The separation matters because the concerns are genuinely different. The marketing surface needs CDN-level performance. The application needs Supabase RLS and dynamic data. The API layer needs execution isolation and longer timeouts than edge functions allow.

The Database

The database is on Azure — specifically Azure Database for PostgreSQL. Not Supabase. The decision: the payment and agent execution data has compliance requirements that made a dedicated managed PostgreSQL instance preferable to a shared Supabase project.

The application layer (app.agenticai01.tech) connects to this Azure PostgreSQL instance via connection pooling. The API layer writes to it directly. The schema is standard PostgreSQL — no Supabase-specific extensions needed.

The Agent Data Model

An agent in the system is a record with:

• —Metadata (name, description, version, author)
• —Capabilities (a structured list of what the agent can do)
• —Pricing (per-run cost, subscription options)
• —Runtime config (model, max tokens, timeout)
• —Tool list (what external APIs it can call)

An agent run is a separate record linked to the agent and the user. Runs have status (queued, running, completed, failed), input, output, token usage, and cost.

This separation — agents as templates, runs as instances — is the core architectural pattern.

The SaaS Deployment Layer

Developers publish agents through a multi-step flow:

1. —Upload agent config (JSON)
2. —Provide a system prompt and capability list
3. —Set pricing
4. —Submit for review

Review is manual right now. As the platform scales, automated review (safety checks, capability validation) will replace the manual step.

Users deploy agents with one click. "Deploy" means: create a run, pass the user's input, return the output. For recurring agents, deploy creates a scheduled job.

Where the Complexity Lives

The hardest problem is not infrastructure — it is trust. When a user deploys an agent, they are trusting the platform (and the developer) with their data and their budget. The platform needs to isolate agent runs so one agent cannot affect another, enforce spending limits before runs execute, and provide transparent logging of what the agent did.

All of these are solved in the current build. They are not hard in isolation. The complexity is that they all need to work together correctly.

---

Resources

• —Azure Functions documentation — the execution platform for the api.agenticai01.tech layer; consumption plan pricing and timeout limits
• —Azure Database for PostgreSQL — Flexible Server — the managed database option with dedicated instance isolation
• —Telegraf.js — the Node.js Telegram bot framework used for the operational command layer

Related Posts

• —3 Subdomains, 1 Azure Database, 1 Vercel Frontend — the full architectural breakdown of how the three layers of this platform are split
• —The New Solo Dev Stack: What Replaced a 5-Person Team in 2026 — why a solo developer can build and maintain a platform this complex without a team
• —Groq vs. DeepSeek vs. Llama-3.3-70B: Why I Mix Models Instead of Picking One — the model routing that powers the agent execution layer

---

Building an AI platform or marketplace? I take on complex multi-layer architectures across Azure, Vercel, and Supabase. See my work or get in touch.