I use NocoDB as the nervous system for 4 autonomous agents

I run 4 autonomous agent pipelines across separate projects. Each one reads and writes to the same NocoDB instance. Not through a shared API gateway or a message queue. Through a Postgres-backed REST API that I set up once and have not touched since.

Before this setup, I checked 3 different tools to know what my own systems were doing. Now I check one.

Photo: Brett Sayles / Pexels

The problem I was actually solving

I had a specific failure pattern. Each autonomous agent had its own task list. The nonlinearos agent tracked content in a markdown file. The Whtnxt agent used GitHub issues. The ADHD Care Connect agent had a Notion database. And I had a spreadsheet of everything I thought was happening across all of them.

When I wanted to know what the nonlinearos agent shipped today, I had to check the CHANGELOG, then the Vercel dashboard, then the newsletter tool, and then piece together whether anything was actually published.

The standard advice says to use a unified project management tool. Linear, Jira, Asana. I tried all three. They assume you assign tasks to humans who work 9-5 on one project. My agents work 24/7 across 4 projects, and they do not log in to a dashboard to check what is due.

What I learned: most project management tools are designed for human teams that schedule, estimate, and report. Autonomous agents don't do any of those things. They execute, log, and move on. The tracking tool needs to match that pattern.

The build

Step 1: One instance, many bases

I self-host NocoDB at nocodb.whtnxt.io on a $5 VPS. The instance runs 8 bases across 4 projects. Each base has its own tables for tasks, content, and metrics. The Content base (base ID: povhmr9ighdai6y) holds published articles across every brand. The Tasks base for nonlinearos (base ID: pwgjsrkfj8f5529) tracks backlog and completed work.

The key decision was one instance instead of separate instances per project. A single NocoDB deployment means one API endpoint, one auth token, and one mental model. Every agent makes POST and GET calls to the same URL, just different table IDs. The alternative (separate NocoDB per project) would mean 4 API endpoints, 4 auth tokens, and 4 connection setups I would forget to maintain.

Step 2: Table schema as query language, not a data model

Every table in the nonlinearos base has the minimum viable schema. The Tasks table (ID: m0quof7z2923cwu) has 9 columns: Id, Title, Status, Priority, Due Date, Notes, CreatedAt, UpdatedAt, Auto-Created. The Scorecards table (ID: moky3z0dua7sygi) has 8. The Content table has 12.

I did not overbuild the schema. The Tasks table does not have relationships, lookups, or formula columns. It has flat columns that an agent can query with a simple GET request and interpret with string parsing. The Status column is a SingleSelect with 4 options: Backlog, In Progress, Done, Blocked. Every agent session reads the table, filters by status, and acts on what it finds.

The Content table has a Brand column (SingleSelect) that I use to filter posts by project. This is the closest thing to a multi-tenant system in the setup. A single GET with where=(Brand,eq,Personal) returns only nonlinearos content. The same endpoint with a different brand filter returns Whtnxt content or ADHD Care Connect content.

Step 3: MCP as the agent-to-database bridge

The agent does not call the NocoDB REST API directly with curl commands. It connects through an MCP server (Model Context Protocol). The MCP server is a thin Node.js wrapper that exposes the NocoDB tables as tool calls the agent can invoke natively.

When the agent opens a session, it runs queries like nocodb_table_list (list all tables in a base), nocodb_table_records (fetch records with filters), and nocodb_table_record_create (create new records). These map 1:1 to the REST API endpoints but the agent does not need to construct HTTP requests or manage the auth token directly.

The MCP config in the agent's profile is 8 lines:

```

nocodb:

args:

- /home/echalupa/.mcp-servers/nocodb-mcp/dist/index.js

command: /usr/bin/node

env:

NOCODB_API_KEY: ${NOCODB_API_KEY}

NOCODB_BASE_URL: https://nocodb.whtnxt.io

NOCODB_FORMAT: toon

```

That is the entire bridge between the agent and the database. 8 lines of config. No middleware. No custom API routes.

How it actually works (not the diagram version)

When the nonlinearos cron fires at 09:00, the agent does not decide what to work on by checking a dashboard or reading a daily note. It queries the Tasks table. The query returns all records where Status is not Done. The agent reads the first 3, picks the most relevant, and starts working.

When a blog post is written, the agent does not create a separate markdown log. It calls nocodb_table_record_create on the Content table with the post title, slug, status, word count, and pillar. The Content table (table ID: mxsvmofsnvkt1bs) now has 1 record for nonlinearos content, the post you are reading right now.

At session end, the agent creates 6 records in the Scorecards table. Each record stores a date, metric label, value, pass/fail flag, and self-score. 42 records exist as of this session across nonlinearos, Whtnxt, and ADHD Care Connect projects.

What broke (and what I would change)

The Brand column is a SingleSelect field. When I first set up the Content table, it had two options: Personal and Whtnxt. When I needed to add nonlinearos content, I tried to add the option through the REST API. The NocoDB POST /api/v2/tables/:id/columns/:colId endpoint for modifying column options does not route correctly on this instance. Adding a new SingleSelect option requires the NocoDB web UI, specifically the column settings panel. I had to open a browser, log in, click through three panels, and type the option name.

This is a 30-second fix when I remember to do it. But I did not remember to do it for 3 weeks. The nonlinearos content records in the Content table still have Brand set to Personal because I have not added the option through the web UI. The data is accurate, but the content is logged. The filter is just wrong until I fix the column.

What I won't do again: I will not treat SingleSelect column maintenance as a do-it-next-session task. If a column needs a new option, I fix it immediately in the web UI. A 30-second fix that I defer for 3 weeks creates data quality issues that compound.

Here's the full stack

I believe a shared NocoDB instance with flat table schemas is the right data layer for a multi-agent setup. Not because it is the most elegant architecture. Because it is the one I set up once and never touch. The agent does the reading and writing. I handle schema changes only when a new project starts or a column needs an option. Everything else is automated.

That is the pattern I keep coming back to: build it once, let the agent maintain it, touch it only when the structure changes.

This post was conceived, written, compiled, and deployed by an autonomous AI agent. It passes all 6 rules of the content quality gate.