When people hear about NRNS, they usually assume it’s a coding tool. Makes sense — AI agents writing code is the headline everyone gravitates to. But coding is one of nine agent types we’ve built so far, and most of them never touch a line of code.
The core idea is simpler than it looks: agents are team members. Some team members write code. Others write blog posts, pull analytics, handle support, or research competitors. The platform treats them all the same — assign a task, agent does the work, you review the output.
The agents we have so far
Beyond the Coding Agent, PR Review Agent, and DevOps Agent on the engineering side, here's what else exists:
Content Engine — give it a changelog and it drafts a release announcement. Give it a feature spec and it writes docs. It handles blog posts, social threads, newsletters.
Growth Analyst — talks to GA4, builds trend reports, analyzes funnels. You can schedule it to run every morning and get a growth summary in Slack without opening a dashboard.
Competitive Intel — monitors competitors, tracks what they're shipping, produces comparison reports.
Customer Success — triages support tickets, answers onboarding questions, escalates bugs. When something gets fixed, it can notify the customer.
Fundraising Agent — researches VCs, drafts outreach emails, tracks your pipeline. Niche, but if you're raising, it saves a lot of manual research.
Chief of Staff — triages your backlog, breaks down goals into subtasks, prioritizes what matters. It doesn't route work to other agents — that's the deterministic orchestrator's job (we wrote about this in the Stripe post). The Chief of Staff decides what needs doing and writes it up; the orchestrator assigns it based on task type and agent skills.
The bridge layer
For non-coding agents to be useful, they need to talk to things outside your codebase. That's what bridges do.
A bridge is a two-way connector between NRNS and an external service. We've built bridges for WhatsApp (via Baileys), Telegram, email over SMTP, and the local file system. Messages come in through a bridge, get filtered on your machine before anything hits the server, and land as tasks or context for agents. Agent responds, reply goes back out through the bridge.
The local filtering part is deliberate. You set allowlists and blocklists per bridge. Only conversations you opt into get forwarded. Your WhatsApp history stays on your phone — NRNS only sees what you tell it to.
On top of bridges, agents access services through MCP tools — structured, permissioned API calls. GA4 data, Stripe subscriptions, GitHub issues, Google Sheets, Vercel deployments, Slack messages. Each tool goes through the same permission system as everything else.
Not every agent needs your laptop
The coding agent runs locally because it needs your codebase and git. But the Growth Analyst doesn't need your laptop — it needs GA4 credentials and somewhere to run. So we built three execution modes:
CLI — local, via the desktop app. File system, git, shell. What the coding agent uses.
API — server-side with tools. Can be scheduled on cron. The Growth Analyst runs here — no desktop needed, works 24/7.
Chat — server-side, text only. No tools, no side effects. For brainstorming or drafting that a human will review.
The orchestrator doesn't care which mode an agent uses. A content task and a coding task look the same from the outside — different agent, different tools, same assign-execute-review cycle.
You stay in the loop
More agent types means more things happening on your behalf. That only works if you can see what’s going on and step in when needed.
Every agent runs under the same permission system. A content agent drafting a blog post can write to the task, but posting it publicly might need your approval. The growth analyst can read GA4, but sending a Slack summary to a shared channel can require a sign-off first. You decide where the line is, per agent, per action.
When an agent needs approval, it pauses and asks. You can approve from the web app, from Slack, or from Telegram — wherever you are. The agent picks up where it left off. No context lost, no restarting from scratch.
Agents can also ask clarifying questions mid-task. If the content engine isn’t sure whether a changelog entry should be technical or marketing-friendly, it asks you instead of guessing. Same for the customer success agent — if a support ticket is ambiguous, it escalates rather than sending a bad reply.
Everything gets logged. Every action, every approval, every question. The audit trail doesn’t care if it’s a coding agent or a marketing agent — same chain, same accountability.
Some workflows we're aiming for
Feature launch: You create a task — "ship the permissions page." Chief of Staff breaks it into subtasks. Orchestrator sends implementation to the coding agent, docs to the content engine, tracking to the growth analyst. Same task system, different agents working in parallel.
Morning ops: Growth Analyst runs at 8am, pulls yesterday's numbers from GA4, posts a summary to Slack. Customer Success checks the inbox, triages tickets, escalates bugs. Nobody opened a dashboard.
No code involved in any of those. Same platform, same permissions, same audit trail. You stay in the loop on everything that matters.
The actual point
There are plenty of AI coding tools — Cursor, Copilot, Devin, Codex. They're good at what they do. We're not trying to out-code them.
What's missing is the layer above. Something that coordinates agents across business functions — content, analytics, support, sales — with proper permissions and oversight. The coding agent matters, but the platform underneath it is the interesting part: task routing, bridges, permissions, memory, audit trails. That stuff is agent-agnostic by design.
A lot of this is still in "works on our machine" territory. But every new agent and integration plugs into the same system, and that's the bet — build the platform right and the agents follow.
