Inspiration

Every useful AI agent we built followed the same loop: write the prompts, wire the tools, code the control flow, deploy, then rewrite half of it when the process changed. Large companies can afford a team for that loop. A freelancer who wants an assistant for their own paperwork can't, and neither can a five-person business that wants a support-triage desk or an approval flow for purchases.

The logic of an agent workflow is mostly configuration: which model, which instructions, which tools, which branch, when to ask a human. So we asked: what if you could draw that workflow, and a runtime compiled it on the fly every time someone used it, with no code generation, no redeploy and no developer in the loop?

What it does

Zonic has two halves that share one workflow document:

1. The visual Agent Builder (https://dev.tripleq.ai/agent-visual-builder-lg/workflows)

  • Drag nodes onto a canvas and connect them: LLM, Agent (a tool-using loop), Swarm (agents that hand a conversation to each other), Sub-flow (reuse another workflow), Rule (branching), Guardrail, Approval and Human input (human-in-the-loop), HTTP request, Database query, MCP tool, Variable, View and Output. There are 18 node types in all.
  • Each node's settings form is generated from a node registry. You pick a Nemotron model per node from a drop-down, write its instructions, and attach tools: any REST API, Python function or database query, configured in a form, not coded.
  • The builder validates the workflow, shows how its agents relate (hand-offs, swarms, sub-flows), imports and exports JSON, and can dry-run its flow in the browser with a mock engine before any model is called.

2. The Agent Runtime and chat (https://dev.tripleq.ai/agent-runtime-lg)

  • Pick any saved workflow in the chat and talk to it. The runtime reads the workflow document, compiles it into a LangGraph graph at run time, caches it per revision and runs it. Change a prompt or a branch in the builder, save, and the next message uses it.
  • Answers stream token by token. Runs pause for approvals or a form and resume later. Long runs can be asynchronous and survive restarts. Answers can include tables, charts, data grids, forms and HTML.
  • Steps under every answer show which node or agent ran, every hand-off and every tool call, so a non-developer can see why the agent did what it did.

Who it's for: individuals and small businesses who want agents tailored to their own process (an inbox and paperwork helper, a customer-support triage desk, a purchase-approval flow, a research assistant over the open APIs they already use) without paying for custom development every time the process changes.

The demo we built with it. To prove the platform on a hard case, we built a multi-agent energy team entirely in the builder, with no code:

  • an Energy Agent that answers bill questions with cited figures from NYC Open Data;
  • a Facilities Agent that explains grid peaks from NYISO load and weather;
  • a Risk Agent that estimates next week's price exposure, behind an advisory guardrail;
  • an All Agents swarm that routes each turn of one conversation to the right specialist.

It uses LLM routing, rule branches, tool-calling agents, concurrent MCP tool calls, a swarm and a guardrail, which covers most of the node types in one realistic workflow.

How we built it

Six open-source services (Apache-2.0), all deployed on AWS, with PostgreSQL on Neon:

  • Agent Builder UI (Next.js, React Flow, Zustand): registry-driven forms, so a new node type is a JSON file, not new UI code.
  • Builder API (FastAPI): validation, import and export, the node registry and the relationship map. It stores data only through the gateway and never sends SQL.
  • Agent Runtime (Python, LangGraph, FastAPI, on ECS Fargate):
    • a document → LangGraph compiler with dialect normalization, a node manifest (kinds, ports, retries, timeouts) and a per-revision graph cache;
    • agents built on LangChain's create_agent, and a swarm with transfer tools and turn limits;
    • SSE streaming with replay, interrupts and resume, a durable queue for async runs;
    • guardrails, hooks, per-model quotas, and traces stored in Postgres.
  • Chat UI (Next.js, Auth.js with Cognito): a streaming chat with reconnect, a server-side proxy that keeps tokens out of the browser, renderers for rich content, and the step timeline.
  • MCP server (FastAPI): one execute tool that runs API, function and database tools sequentially, concurrently or as a dependency pipeline. Tool definitions come from the workflow, so new tools are configuration.
  • PostgreSQL gateway (FastAPI): named views and procedures per caller, with grants. Every service goes through it.

NVIDIA Nemotron on Nebius Token Factory. Token Factory is OpenAI-compatible, so Nemotron models are entries in the runtime's model catalog (nemotron-3-nano, -super, -ultra, nemotron-3.5-super-vl), each with its own quota. The builder offers the same codes in every model drop-down, so the workflow author chooses the model for each step. Following the track's advice, the demo tiers them, each choice made by running the real workflows:

Role in the demo Model Why
Question router, lane redirect Nemotron 3 Nano Fast and cheap for one-line decisions
Tool-calling specialist agents Nemotron 3 Super Reliable tool calls at a fraction of Ultra's cost
Swarm coordinator, risk reasoning Nemotron 3 Ultra Multi-step reasoning. Super sent invalid hand-off arguments in about 2 of 3 swarm transfers; Ultra's were valid.

Challenges we ran into

  • Compiling arbitrary graphs safely. Users draw cycles, branches, parallel paths and nested sub-flows. The compiler normalizes builder dialects, analyses the graph before it runs (reachability, joins after parallel branches, loops) and enforces per-node visit limits and a per-run step limit, so a bad drawing fails with a clear error instead of hanging.
  • Nemotron reasons before it answers, and the reasoning counts toward max_tokens. Short-answer nodes such as routers returned truncated JSON at 200 tokens until we raised their budgets.
  • Token usage was counted 100 times over. Token Factory's Nano and Ultra put a running usage total on every stream chunk, and LangChain added them up: one 7-call run reported 3.6M tokens. We wrote a ChatOpenAI subclass that counts usage only from the closing chunk.
  • Follow-up questions led to made-up numbers. With chat history, a router sometimes answered in prose instead of JSON, and the question fell to a step without data tools. We made routing fail-safe in the workflow itself, by changing configuration in the builder with no code change. That's the platform working as intended.

Accomplishments that we're proud of

  • Workflows are data, not code. The four demo agents are canvases. A new agent is a new drawing, and a change is a save, not a deploy.
  • One document, two products. The builder and the runtime share the node registry, and contract tests in CI keep them in sync.
  • Real multi-agent patterns: hand-offs, a swarm, sub-flows, human approval and guardrails, all drawable and all visible in the chat's step timeline.
  • Tested: about 1,600 runtime tests (unit, compiler, conformance, golden scenarios with a scripted model), plus builder, MCP and gateway suites and live checks on the deployed stack. The demo's figures match their open-data sources to the cent.

What we learned

  • Most of an agent is configuration. Once the runtime owns the hard parts (streaming, resume, retries, quotas, traces), the remaining decisions are ones a non-developer can make on a canvas.
  • Model choice belongs in each node: Nano, Super and Ultra fit different jobs, and letting the author pick per step keeps apps fast and cheap.
  • Deterministic tools plus visible steps are what make users trust an agent. The model explains; the tools fetch and calculate.

What's next for Zonic

  • Templates for personal and small-business workflows (inbox triage, quotes and invoices, support desk, approvals) to start from instead of a blank canvas.
  • Scheduled and event-triggered runs (Nebius Serverless Jobs) for workflows that run themselves.
  • Nemotron 3.5 Super VL for image input: receipts, forms and screenshots.
  • One-click sharing of a workflow as a chat link, and team workspaces with per-user ownership.

Built With

  • amazon-cognito
  • aws-ecs-fargate
  • aws-lambda
  • cloudfront
  • fastapi
  • langchain
  • langgraph
  • mcp
  • nebius-token-factory
  • neon
  • next.js
  • nvidia-nemotron
  • postgresql
  • python
  • react
  • react-flow
  • typescript
  • zustand
Share this project:

Updates

Submission history