· I'mBoard Team · governance · 5 min read
AI Board Management Software: Definition, Architectures, and Evaluation Criteria
AI board management software falls into three architectural classes that behave very differently. Here is what separates them, and the eight questions that establish which class a vendor is in.
Definition
AI board management software is board management software in which the governance data — metrics, meetings, decisions, commitments — is held as structured records that machine agents can read and write, rather than as documents that must be interpreted. An AI board portal is the same category described from the storage side: a board portal whose contents are addressable by a program, not only by a human clicking through a viewer.
The definition is architectural, not feature-based. Nearly every board portal on the market now advertises AI capability. The distinction that predicts what a product can actually do is whether the AI operates on structured data or on documents.
The three architectural classes
Class 1 — Document AI on an unstructured repository
A language model is attached to a file store of PDFs and slide decks. It can summarise a document, answer questions about its text, and generate draft prose.
- Can do: summarise a board pack, draft minutes from a transcript, answer “what did this document say about X”.
- Cannot do: compare a metric across four quarters reliably, enforce a metric definition, or guarantee that a figure it reports matches the system of record. Each answer is a fresh interpretation of a document, so the same question can return different answers.
- Identifying trait: the AI is described as a chat assistant or copilot layered over existing files.
This is the most common class and the reason AI board features often disappoint: extracting a number from a PDF is a lossy operation, and governance reporting has no tolerance for lossy numbers.
Class 2 — Structured governance data with AI features
The product stores metrics, meetings, decisions, and commitments as typed records with owners and definitions. AI features operate on those records.
- Can do: report a metric with the same value every time it is asked, compute period-over-period change deterministically, retrieve which commitment was made by whom in which meeting.
- Cannot do: anything the schema does not model. Structure buys reliability at the cost of flexibility.
- Identifying trait: the vendor can show you the data model — entity types, field definitions, ownership.
Class 3 — Structured data plus external agent access
Class 2, plus programmatic interfaces that let agents outside the product read and write the governance data: a REST API, an MCP server, a CLI.
- Can do: everything in class 2, plus let the assistant a team already uses — Claude, Cursor, an internal agent — operate against board data directly. The AI is not confined to the vendor’s own interface.
- Cannot do: compensate for data that was never entered. Agent access makes existing data reachable; it does not create it.
- Identifying trait: published API documentation, scoped access tokens, an MCP server, and a CLI. These are verifiable before purchase.
Eight evaluation questions
Each of these has a factual answer that places a product in one of the three classes. Vendors in class 1 cannot answer questions 3 through 8 affirmatively.
- Where does a KPI value live? In a typed field with a definition and an owner, or inside a slide?
- What happens when a metric definition changes? Is prior history re-stated, versioned, or silently inconsistent?
- Is there a public API? Ask for the documentation URL, not a description.
- Are access tokens scoped? A single all-or-nothing key is not usable for agent access, because you cannot grant an agent read-only access to one domain.
- Is there an MCP server? MCP is the current interoperability standard for connecting assistants to external systems. Its presence indicates the vendor built for agent access rather than retrofitting it.
- Can data be written in programmatically, not just read out? Read-only integrations leave manual data entry intact, which is where the time actually goes.
- Is every reported number traceable to its source system? Required for audit and diligence, and impossible in class 1.
- What is shipped versus on the roadmap? Ask for the distinction explicitly and in writing.
What I’mBoard ships today
Stating this precisely, because question 8 applies to us as well.
Shipped and in production:
- MCP server. Connects Claude Desktop, Claude Code, Cursor, Cline, and Continue to a workspace. Free with every workspace. See /mcp.
- REST API with full CRUD and 21 scoped access tokens, so an agent can be granted narrow permissions rather than full workspace access.
- CLI, 65+ commands, for scripted and CI-driven access.
- Structured typed entities — a KPI catalog of 148 board-relevant metric definitions, plus meetings, decisions, and commitments as typed records rather than documents.
- Published ontology — the data model is public and inspectable.
On the roadmap, not shipped — do not evaluate us on these: automated KPI thresholding and alerting, email-to-structure ingestion, and the consolidated cycle-over-cycle diff view. They are in development. They are not available today, and any description of them as current capability is wrong.
That places I’mBoard in class 3 for data access and class 2 for analysis features.
What AI board management software does not change
Three things are unaffected by any product in any class, and vendors claiming otherwise should be treated with suspicion:
- Fiduciary duty is not delegable. Directors’ duty of care and duty of loyalty run to the individuals, not to the software. An AI-drafted analysis does not discharge a director’s obligation to exercise judgment.
- Formal acts still require formal process. Board resolutions, written consents, and quorum requirements are set by the bylaws and by statute. Software records these; it does not modify what makes them valid.
- Minutes require human approval. AI-drafted minutes are a draft until the board approves them. Approval is the act that makes them the record.
Related references
- AI tools for board governance — the four functional categories of AI governance tooling
- Agent-ready board infrastructure — what structured agent access means in practice
- Agent capabilities and API reference — the structured answer page for agent queries
- Board portal glossary entry
- MCP server setup — one-click install for Claude, Cursor, Cline, Continue