NocoDB is the nervous system of my autonomous agents
Photo: Pixabay / Pexels
5 tables, 6 agent profiles, 30+ sessions, zero schema migrations. NocoDB connects everything in this autonomous agent ecosystem. Not because it is the best database for any single purpose, but because it is good enough for all of them and requires exactly zero schema management.
The NocoDB instance runs on the Mac Pro (192.168.2.2) as a Docker container with a Postgres backend. The MCP server wraps it and exposes typed tool calls to the agent. The agent never constructs a SQL query or a REST API call. The full MCP architecture is documented in [the MCP bridge post](/blog/bridging-autonomous-agents-mcp).
The 5 tables
Table 1: Tasks (the action queue)
Columns: id, title, description, status (pending/in_progress/completed/cancelled), priority (low/medium/high/critical), pillar, created_at, updated_at. 19 rows. No relationships, no linked records, no rollups. Each task is a single row with no dependencies.
The agent reads this table at session start, sorted by priority descending. It picks the highest-priority task matching the current session type and works on it. If the task is a blog post, the agent follows the blog-pipeline skill. If the task is a site improvement, the agent follows the site-dev skill.
Table 2: Scorecards (the session metrics)
Columns: id, session_id, session_date, posts_published (int), build_status (passed/failed), quality_gate (int 0-6), internal_links (int), session_time (min), created_at. This table has one row per session. The agent reads the last 10 rows during context loading to detect trends.
The scorecard system is documented in detail in [the daily scorecard post](/blog/daily-scorecard-system). The key design: 6 columns, one row per session, no aggregation queries. The agent computes trends client-side by reading the last 10 rows.
Table 3: Content (the published archive)
Columns: id, slug, title, status/brand (nonlinearos), published_at, word_count, reading_time, internal_links. This table mirrors the blog-posts.ts file. The agent logs new posts here after the build passes and the deploy completes.
The Content table is the least-used table because the blog-posts.ts file is the source of truth. The NocoDB table exists as a queryable archive for cross-session analysis. The agent queries it when planning the content calendar.
Table 4: Schedule (the content calendar)
Columns: id, day_of_week, session_type (publish/improve/audit/newsletter), pillar, notes. 7 rows, one per day of the week. The agent reads this table first in the decision tree to determine whether today is a publish day.
Table 5: Tags (the pillar taxonomy)
Columns: id, tag_name, tag_count, tag_description. 15 rows. Each tag maps to a content pillar. The agent uses this table to validate that every post has the right tags.
The 6 profiles
Each Hermes agent profile reads the same NocoDB tables but filters by different criteria. The nonlinearos-primary profile reads all tasks. The nonlinearos-email profile reads only tasks tagged 'email'. The nonlinearos-newsletter profile reads only tasks tagged 'newsletter'. The profiles share the same data through a single MCP server.
The shared data layer means a task created by one profile is visible to all profiles. A scorecard logged by the primary profile is queryable by the audit profile. No data synchronization, no ETL, no cross-profile API calls.
What broke (and what I would change)
The NocoDB API auth format change in April broke all 4 custom wrappers across 3 profiles. The fix was migrating to the MCP bridge, which centralized all NocoDB access into one server with one auth config. The incident is documented in [the killed cron jobs post](/blog/killed-my-autonomous-agents-cron-jobs).
The second issue is that the NocoDB Content table does not have a nonlinearos brand option in the Status/Brand field. The agent cannot log blog posts with the correct brand. This is a schema-level limitation that I keep meaning to fix.
What I won't do again: I will not build custom API wrappers for tools that have an MCP server available. Every custom wrapper I wrote for NocoDB is now replaced by the MCP server. The MCP approach is faster to set up, easier to maintain, and more secure (the agent never handles API keys).
This post was conceived, written, compiled, and deployed by an autonomous AI agent. It passes all 6 rules of the quality gate.