All solutions & products

Commind — Collaborative
Intelligence

Role
Creator & Architect
Product
Homegrown — collaborative AI knowledge platform
Scope
Product design, roadmap, UI/UX & architecture
Outcome
4 agentic systems in a permission-scoped space model

Commind is a collaborative AI knowledge platform — an AI "team brain," where agentic workflows plan, use tools, and act autonomously across a team's knowledge, meetings, and the web — always bounded by which knowledge the requester is allowed to see.

It didn't begin as a mandate. Commind started as a problem statement I drafted for an internal hackathon; after seeing what the teams built around it, we decided to turn it into a real product. We knew the idea wasn't novel — there were established players in the space — but none of them did the whole job. The pieces existed; nothing tied them together. So we decided to build it whole.

In a few days I had the product design, roadmap, and UI/UX; from there I defined the architecture and engineering specs, and then it was full-on execution. What follows is the agentic layer at the heart of the product — the space model it runs inside, and the engineering judgment to know when not to use an agent.

4 systems
agentic workflows spanning knowledge, meetings, and the web — each one built to plan, use tools, and act, every action bounded by the requester's space membership.

The substrate: a space model the agents run inside

Before any agent, there's a permission model. Every agentic action in Commind is space-scoped, least-privilege, and zero-trust: an agent can only ever read what the requesting user's space membership permits, enforced on every access rather than bolted on as a filter afterward.

  • Personal Space. Private and owner-only; the default landing zone where all ingested content and research findings stage before promotion.
  • Team Spaces. Role-gated (owner / contributor / viewer) with visibility tiers that run private → discoverable → org-public.
  • Organization Space. (Roadmap) Org-wide, auto-aggregated from org-visible team spaces.
  • Client Space. A purpose-built sandbox separating Client Context (master documents) from other data — the boundary the Sales Intelligence agent reasons within.

The hierarchy makes knowledge progressively discoverable — personal → team → org — and gives every agent a built-in permission boundary instead of a bolted-on one. Space membership is the agent's authorization.


The agentic systems I architected

Built / in build

1 · Deep Research — a planner–executor loop

Decomposes a topic into sub-queries, runs multi-query web searches through a tool API, cross-references sources, and synthesizes a structured, cited report. Streams a transparent research trail — plan, search, cross-reference, synthesize — and degrades gracefully, returning partial findings on timeout rather than failing outright. Findings stage into the user's Personal Space for later promotion, closing the research → ingest → retrieve loop.

Built / in build

2 · Meeting Intelligence — perceive → reason → act

Autonomously ingests Teams transcripts via a delegated Graph API, summarizes them, extracts action items, resolves assignees against meeting-participant scope, and pushes tasks into Planner, To Do, Jira, and Linear. It writes only to Team and Client spaces, never Personal — a deliberate scoping rule so meeting outputs land where the team can act on them.

Built / in build

3 · Intent-routed retrieval orchestration

The RAG reasoning layer: Query → Understand → Expand → Hybrid Retrieve → Rerank → Assemble → Generate. Scope detection routes each query across the space hierarchy — "my docs" to Personal, "our project" to Team, "company policy" to Org — then blends dense retrieval (HNSW), sparse retrieval (BM25), and metadata filtering, with confidence thresholds and citation enforcement as generation guardrails.

In active buildout

4 · Domain-scoped conversational agents

Stateful generation agents (Create, Sales Intelligence Brief) that maintain outline and source-ID state, re-query the knowledge base on demand, and explain their own reasoning. The Client Intelligence Brief operates within a Client Space under a precedence rule: meetings win on currency, master documents win on facts of record.


Signature architectural judgment

  • Agentic when warranted, deterministic when better. I chose synchronous, debuggable pipelines and a one-report-per-conversation state machine over open-ended agent loops, and deliberately deferred a full agent/MCP layer until the RAG and space foundation was solid. The hardest call in agentic engineering is usually the one against using an agent.
  • Governance by design. Space membership is the agent's authorization boundary — not a filter applied after the fact. An ambiguous assignee results in no action taken rather than a confident wrong one, and every agent is scoped strictly to the knowledge the requester is permitted to see.
  • Least-privilege by default. Delegated, user-controlled OAuth (PKCE) means agents act per user — never through admin service accounts. The system can only ever do what the person it's acting for could do.
The hardest call in agentic engineering is usually the one against using an agent.

Capabilities demonstrated

Multi-agent orchestration Planner–executor design Perceive–reason–act pipelines Space-scoped, least-privilege agent execution Tool-use integration (Graph API, task managers, web & vector APIs) Hybrid RAG & scope-aware retrieval routing Conversation state & lifecycle design Agentic-vs-deterministic trade-off judgment

Have a similar challenge?

If you're building an agentic layer that has to plan, use tools, and act autonomously — safely, inside a permission model you can defend, and with the judgment to know where an agent doesn't belong — let's talk.

Get in touch →