Monospace is a new product for giving AI agents safe access to company data, from Monospace Inc., the company behind Directus. In our tests, a coding agent connected to it over MCP and answered questions about our data correctly. But the agent only found Monospace when we searched for its tagline, and for Monospace's own use case it recommended other tools, including Directus.
Four days after launch, we put Monospace through our agent experience (AX) audit, following our AX audit method. The audit has four stages:
- Awareness: does the model know Monospace without searching?
- Discoverability: can an agent find Monospace when it's looking for a tool like it?
- Reputation: does the agent speak well of Monospace, and recommend it over other options?
- Integration: can the agent build a working proof of concept with Monospace?
How we tested
All testing used Claude Opus 5.5 (
claude-opus-5-5) in Claude Code 2.1.285, on 6 October 2026. Every session started in a fresh, empty folder with no project files, memory, MCP servers, skills or plugins. Awareness questions ran with no tools at all, and discoverability and reputation questions with web search and web fetch only. We ran each prompt once, so treat these results as one developer's experience rather than a benchmark.
Scores at a glance
Agents don't know Monospace, and only find it when they search for its own tagline. Once they do find it, they like the design but hedge every recommendation, and often fill gaps with facts about Directus. In the integration, the agent installed Monospace, loaded our data and answered questions over MCP with a few short human steps, but the free plan blocks the governance features Monospace leads with.
- Awareness: FAIL (1 / 4) — Unknown from memory; the name only brings up the Directus company
- Discoverability: POOR (2 / 4) — Found only by searching its own tagline, and not even then in one of three tests
- Reputation: POOR (2 / 4) — Liked, never recommended outright; facts often wrong or borrowed from Directus
- Integration: OK (3 / 4) — Working MCP integration with correct answers; field-level permissions blocked on the free plan
- Overall: POOR (2 / 4) — Works once an agent knows it exists; getting there is the hard part
See our AX audit rubric for how we score each stage.
Awareness: does the model know Monospace?
Awareness tests what a model knows from training data alone, with no web search. For a product launched four days earlier, we expected the answer to be no. What matters is how the model fails, whether it admits it doesn't know, makes something up, or confuses Monospace with something else.
FAIL (1 / 4) — Unknown from memory; the name only brings up the Directus company
- FAIL: Unknown, or confused with something else
- POOR: Recognises the name, details vague or invented
- OK: Accurate description from memory
- GOOD: Accurate, and recommended unprompted
We started with two questions that describe Monospace's pitch without naming it. Each answer below comes from a fresh session with no tools.
The first answer describes the gap Monospace says it fills, and the second picks a competitor with confidence. Then we named Monospace:
Given the domain, the model knew the company but not the product. Given the tagline, it said it didn't know. It never invented features, which is good behaviour, but a developer asking their agent about Monospace today either hears about Directus or gets "I don't know". In other sessions the agent also raised two name clashes, monospace fonts and Google's old internal "Monospace" codename for what became Project IDX.
- Awareness: FAIL (1 / 4) — Unknown from memory; the name only brings up the Directus company
What Monospace can do about it
Training data catches up slowly, so there's no quick fix here. The useful work is making sure the next training cut sees Monospace as a product in its own right. That means launch posts, guides and comparisons that pair the name with what it does ("Monospace, the governed API layer from Directus").
Discoverability: can an agent find Monospace?
Discoverability tests whether an agent with web search finds the product when it's looking for something like it. We ran three six-question "funnels" in a single session each. Each funnel starts with a broad problem and narrows towards Monospace one question at a time, then names it at question 6. We recorded the first question where Monospace appeared.
POOR (2 / 4) — Found only by searching its own tagline
- FAIL: Only appears when named
- POOR: Only appears with its own positioning language
- OK: Appears for a specific description of the problem
- GOOD: Top choice for broad problem descriptions
Each funnel asks from a different angle, because different people describe the same problem differently.
| Funnel | Who's asking | First question | Where Monospace first appeared |
|---|---|---|---|
| A | A team wanting agents to use company data | "My company wants to let AI agents work with our internal data…" | Question 5, which used Monospace's own tagline |
| B | A backend developer | "What's the best way to put one API in front of several databases…" | Question 6, only when we named it |
| C | Someone building agents | "I'm ending up with a separate MCP server for every system we have…" | Question 5, which used Monospace's own tagline |
Here are funnel A's six questions, asked in one session, with the start of each answer.
At question 3, the agent searched the web for a product that does what Monospace does and concluded that none exists. In funnel C it said the same thing in different words: "No product does this as a drop-in layer, and a gateway can't do it reliably."
Funnel B, the developer's angle, went worse. At question 3, the agent recommended Monospace's parent company's older product for Monospace's job:
And searching for Monospace's own tagline didn't find it either:
Once found, Monospace became the agent's top pick in all three funnels. It called Monospace "the closest match to your requirements of anything I've found" in funnel A, and "the best conceptual fit of everything we've looked at" in C. In B it said "the product is brand new but the team isn't." Each time it added the same caveat, that Monospace was days old and unproven.
- Discoverability: POOR (2 / 4) — Found only by searching its own tagline, and not even then in one of three tests
What Monospace can do about it
Publish pages built around the problems agents are asked about
Agents ran searches like MCP gateway agent identity fine-grained authorization audit log Postgres SaaS 2026 and AI agent data access control plane field-level permissions MCP new product 2026, and none of them surfaced Monospace. Guides and docs titled around those problems, in a developer's words, would give agents something to find.
Get into the comparison articles agents already read
The recommendations agents made instead came from vendor comparison posts and round-ups, Bytebase and Cerbos blog posts, Product Hunt, and MCP directories like Glama. That's where Hasura, WunderGraph Cosmo, DreamFactory and Cerbos got their mentions.
Separate Monospace from Directus on purpose
In funnel B the agent recommended Directus for Monospace's use case. A clear "Monospace vs Directus: which should I use?" page on both sites would teach agents when to send developers to which product.
Reputation: do agents recommend Monospace?
Reputation tests what the agent thinks once Monospace is named, including whether it recommends it over competitors and whether it gets the facts right. We ran eight questions, each in a fresh session with web search. Hasura and WunderGraph Cosmo were among the competitors the agent named most often before it found Monospace. We added Directus on purpose, because of funnel B.
POOR (2 / 4) — Liked, never recommended outright; facts often wrong
- FAIL: Not recommended, or core facts wrong
- POOR: Heavy caveats, facts unreliable
- OK: Recommended for specific scenarios, facts mostly right
- GOOD: Recommended over alternatives, facts right
| Question | Verdict |
|---|---|
| What do you think of Monospace for governed agent access? | "Worth a proof of concept, but I wouldn't put it in production yet." |
| Monospace over Hasura? | No: "use Hasura for production now, and run a small trial of Monospace alongside it" |
| Monospace over WunderGraph Cosmo? | Yes, conditionally: "I'd lean towards Monospace for what you described" |
| Monospace over Directus? | Yes, conditionally: "mainly because you need internal APIs as well as Postgres" |
| 20-person startup on Postgres, Stripe and HubSpot | "Not yet. It's aimed at your exact problem, but two of your three systems aren't supported today." |
| Regulated company needing self-hosting, SSO and a full audit trail | "Yes, it's worth shortlisting, but don't approve it yet." |
| Main risks of adopting Monospace (name only) | Couldn't identify it, and answered about a font |
| Pricing and licensing vs Hasura and Cosmo (name only) | Priced Directus instead, "fairly confident (~75%)" |
Whenever the agent found Monospace, it liked the design. For a regulated company, it called it "the right design for a regulated environment: agents never hold database credentials directly." But it never recommended Monospace without conditions, and most verdicts came back to how new it is.
The answers' quality depended on which pages the agent reached. The most accurate answer, the startup "Not yet", came from Monospace's own homepage, pricing page and connectors page. It found that Stripe and HubSpot are listed as "Coming Soon", and that row/column-level security and audit logs aren't on the free plan. When the agent read less, it filled the gaps with outdated or borrowed information:
| What the agent said | What's true |
|---|---|
| Monospace's pricing isn't on the site | It's at monospace.io/pricing |
| Monospace has a GraphQL API | No GraphQL API is documented. It offers REST, an SDK and MCP |
| Directus's licence is "BSL" | Directus moved to its own MSCL licence in 2026, and that licence is Directus's, not Monospace's |
| Monospace costs $499/month on a Team plan | That's Directus Cloud pricing. Monospace has a free Starter plan, then custom-priced Business and Enterprise plans |
| "The product page never names Postgres" | True. Postgres support is only listed on the connectors page and in the docs |
The two questions that named Monospace without its domain went worst:
For the risks question, the agent searched for "Monospace developer tool" and "Monospace launch 2026", and neither search found the product. The pricing comparison never reached monospace.io.
Monospace vs Directus
Directus is Monospace Inc.'s older product, and it has its own MCP server. When we asked whether to choose Monospace over Directus for exposing Postgres and internal APIs to apps and agents, it leaned towards Monospace, "mainly because you need internal APIs as well as Postgres". Its reasoning was that Directus is built around a single SQL database, while Monospace applies one permissions model across several sources. It described the two as "a sibling product, not an unknown vendor", and still pointed teams that only need Postgres towards Directus, for its proven field-level permissions and its admin UI.
- Reputation: POOR (2 / 4) — Liked, never recommended outright; facts often wrong or borrowed from Directus
What Monospace can do about it
Put the key facts on the pages agents read first
The homepage was the page agents read most, and it doesn't name Postgres or state a licence. Agents that stopped there guessed both. A line on the homepage naming the supported databases, the licence and where pricing lives would have fixed several wrong answers.
Settle "public preview" or "GA"
Monospace's launch article calls it a public preview, and the Directus community announcement calls it GA. Agents picked up both ("Their own posts disagree on whether it's "GA" or "public preview""), and used "preview" as a reason not to recommend Monospace for production. One status everywhere would remove that reason.
Publish what agents told our test user to ask sales
For the regulated company, the agent listed five questions to ask Monospace's sales team. They covered whether audit logs record the full query, whether the log is tamper-evident and can stream to a SIEM, whether SAML or OIDC work self-hosted, what licence covers self-hosting, and what compliance reports exist. Docs pages that answer those would give agents what they need to move past "don't approve it yet".
Integration: can an agent build with Monospace?
Integration tests whether an agent can install the product and build a "hello world" with as little human help as possible. We gave it three spreadsheets for a fictional business (50 customers, 30 products, 300 orders with 741 line items) and asked it to:
- Set up Monospace and give us a localhost link.
- Get the spreadsheet data into Monospace and connect itself to it.
- Answer a question using Monospace: which region had the most revenue in the last three months, and who were its top three customers?
- Create a restricted key for an "analyst" agent that can't see customer emails, and prove it.
- Mark one order as refunded through Monospace.
We ran it in Claude Code's default permission mode, approving each command, so we could stop the agent from reading anything outside its folder. Monospace has no hosted signup ("Get Started" leads to a contact form), so the agent had to self-host it with Docker.
OK (3 / 4) — Working MCP integration; field-level permissions blocked on the free plan
- FAIL: No working hello world
- POOR: Works, but needed several human steps
- OK: Works with short human steps and minor workarounds
- GOOD: End to end, governance included, at most one human step
Installing: one hint, then four minutes
We replied "It's the one at monospace.io.", and the agent then read the installation page, downloaded the official Docker Compose file, and had Monospace v1.0.0 running with Postgres, RabbitMQ and Redis in 4 minutes 12 seconds, with no errors.
Creating the admin account, accepting the licence agreement and creating a workspace took us 6 and a half minutes in the browser, with no email verification. The last onboarding screen shows how to connect Claude Code (a claude mcp add command) and how to install Monospace's agent skills plugin.
Loading the data and connecting over MCP
Monospace's homepage illustrates its data sources as files like customers.xlsx and inventory.xlsx, but its connectors are PostgreSQL, MySQL and MariaDB, with no spreadsheet connector. The agent worked this out from the docs and took a sensible route. It converted the spreadsheets to SQL, loaded them into a new database inside Monospace's own Postgres container, and registered that database as a data source through Monospace's API. Monospace detected the relationships between the tables on its own, and the agent checked that every table's row count matched the spreadsheets.
The agent leaned heavily on Monospace's agent-friendly docs, including llms.txt, the 1.4 MB llms-full.txt, and raw Markdown versions of each docs page. The agent said the OpenAPI spec served by the running instance "mattered most". The docs have no request examples for creating a data source, so it worked out the format from that spec, by trial and error.
It then needed one thing it couldn't do itself, an API key. It asked us to create one in the UI and write it to a file with a ! pbpaste command, so the key never appeared in the chat. With a key in place, the agent tested Monospace's MCP server by hand with curl and found 7 tools. It then wrote a project-level .mcp.json that reads the key from the file at runtime, so the key isn't stored in the config either. Claude Code needed a restart to load the new MCP server.
The hello world: a correct answer
| Top customers in North | Revenue (paid and shipped orders) | Orders |
|---|---|---|
| Omar Patel | $19,744.22 | 5 |
| Mateo Patel | $15,575.57 | 4 |
| Sipho Dube | $13,420.81 | 4 |
Every figure matched what we calculated from the spreadsheets beforehand. The agent stated its date window and which order statuses it counted, showed how the ranking changes if pending orders are included, and cross-checked the result in Postgres.
Monospace can't calculate totals itself (its docs have a page called "No Aggregates"), so the agent pulled the rows through MCP and added them up in a Python script. That's fine for 300 orders, but a bigger dataset would mean moving a lot of rows through the agent's context.
Field-level permissions: blocked by the free plan
Asked for a restricted "analyst" key that can't see customer emails, the agent read the access control docs, built a policy, and tried to create it. Monospace refused, and the agent queried Monospace's licence API to find out why:
Starter licence limit (from /api/system/license) |
Value |
|---|---|
| Custom policies (needed to hide a field) | 0 |
| Custom roles | 0 |
| Service accounts (needed for a separate agent identity) | 0 |
| Workspaces | 1 |
| Seats | 3 |
It confirmed nothing had been half-created, and declined to fake the result by hiding the column in Postgres instead, saying that "isn't what you asked for".
This matches Monospace's pricing page, which lists row/column-level security, service accounts and custom roles and policies as Business-plan features. But it means the features Monospace leads with, per-agent identities and field-level rules, can't be tried on the free self-hosted version without contacting sales. The agent also noted that the licence limits weren't on any docs page it read. It only found them through the API, after being refused.
A live write: done
What it took
| Human step | Why |
|---|---|
| "It's the one at monospace.io." | The agent's search for Monospace found only fonts |
| Admin account, licence agreement, workspace (7m 27s) | Expected, since a person has to accept the licence |
| Create an API key in the UI | Agents can't create their own key |
| Restart Claude Code | Needed to load a newly added MCP server |
The whole session took about an hour and a half, including our steps. The agent never used Monospace's agent skills plugin, SDK or CLI. It skipped the skills plugin because "it wasn't needed for this".
- Integration: OK (3 / 4) — Working MCP integration with correct answers; field-level permissions blocked on the free plan
What Monospace can do about it
Let people try governance without a sales call
A trial licence that a developer can get without contacting sales, or a small allowance of custom policies and service accounts on the free plan, would let agents demonstrate per-agent identities and field-level rules.
Document the free plan's limits where agents look
Put the Starter limits (0 custom policies, roles and service accounts) in the docs next to the access control and API key pages, so an agent can tell a user before it builds a policy that can't be saved.
Add request examples for the API calls agents need
Creating a data source and writing a policy were the two places the agent had to guess. One complete example request for each would remove most of the trial and error.
Make the API keys page point to personal keys
On the free plan, the prominent API Keys page leads to a paywall, while the working option is under Account → Access. A link from one to the other would save the confusion.
What this means for Monospace
Monospace has built a lot for agents. It has an MCP server, llms.txt and llms-full.txt, Markdown docs, an OpenAPI spec on every instance, an agent skills plugin, and an onboarding screen that tells you how to connect Claude Code. Once an agent was connected, it loaded data, answered questions correctly and made live writes, all through MCP.
The problems come before and around that:
- Agents only found it by searching for its tagline, and in one test the agent recommended Directus for its job.
- Without the domain in the prompt, the agent either couldn't identify it or priced Directus instead.
- Field-level permissions and agent identities can't be tried on the free plan.
The first two are fixable with content, such as pages built around the problems agents get asked about, clear "Monospace from Directus" naming, and the key facts on the homepage. The third is a pricing decision, but documenting the limits would at least stop agents and developers from running into them by surprise.
Cloudflare's isitagentready.com, which checks how readable a website is for AI agents, scored Monospace's docs at docs.monospace.io 20 out of 100. Those are the docs the agent relied on in the integration, through their llms.txt and Markdown pages.
Top comments (0)