NYSA

Nysa is an AI chief of staff that knows your life and your companies, attends the meetings, keeps the knowledge current, and makes sure the work gets done.

Comment

Inspiration

I watched other cofounders hold their post-meeting life together with duct tape. Fathom records the meeting, fires a webhook into an agent runner, which updates Notion and sometimes drafts an email. It takes hours to build, it breaks all the time, and honestly only a technical person could keep it running. Every COO we talked to loses real hours after meetings writing notes, updating docs, and chasing down who said they'd do what.

Here's what clicked for me: the problem was never transcription (Granola and Fathom have that covered), or storage (Notion), or search (Glean). It's that no one owns the whole loop — meeting to updated knowledge to follow-up that actually happens to a commitment someone tracks. That's why I built Nysa, an AI chief of staff that owns that loop end to end. Every meeting updates the company and pushes the work forward, and the human only gets pulled in when something actually needs their judgment.

What it does

  1. Capture — a bot joins the meeting and captures it with speaker identification.
  2. Understand — Nysa extracts decisions, commitments, owners, due dates, and updates the company brain
  3. Update — structured operating memory is updated; every piece cites its sources.
  4. Act — she drafts the emails, tasks, and calendar actions; executes automatically where allowed, requests approval where judgment or risk requires it.
  5. Close — tracks each commitment until it's done, dropped, or explicitly waiting on someone.

No workflow canvas, no webhooks, no prompt maintenance. You buy the outcome, not the machinery.

How I built it

Two layers, and the second one is the unusual part:

The product is TypeScript everywhere: a standalone Node API service (the only door to data and actions), a React + Vite SPA as its first client, and Postgres as the only datastore — pgvector for embeddings, built-in full-text search, and a Postgres-backed transactional job queue (jobs are created in the same transaction as the data that triggers them, so "meeting saved but extraction never queued" cannot happen). Multi-tenancy is enforced by the database itself: Row-Level Security on every tenant table with FORCE ROW LEVEL SECURITY, so a missed filter in app code returns zero rows instead of leaking across workspaces. The agent harness is thin and custom.

The factory: Nysa is built and operated by an autonomous software factory. Seven agent roles — dispatcher, planner, spec-linter, test-author, builder, reviewer, narrator — work tickets on a Linear board, deliberately split across model families (the builder can't edit tests, and CI enforces it; the reviewer runs on a different model family than the builder). A human sets priorities and approves from plain-language evidence bundles, never from raw diffs. Budgets live in the run wrapper, not in prompts, so agents can't raise their own limits.

Challenges I ran into

  • Making tenant isolation impossible to break, not just unlikely. Agent-written code will eventually forget a WHERE workspace_id. We moved the wall into Postgres RLS, closed the side doors (object storage access only through workspace-checked signed URLs; traces and job rows are tenant data too), and wrote CI tests that prove the hostile case — forged workspace context reads zero rows across vector search, full-text, and job tables.
  • Trusting agents to build the product. Early on, one model doing everything meant tests that conveniently passed. The fix was structural, not prompt-based: separate roles, separate model families, append-only history enforced by database grants, and human approval gated on evidence.
  • Killing our own architecture twice. We went from a hybrid layer on Notion/Drive, to a git-backed markdown brain, to native Postgres — because agent-authored data is transactional (a processed meeting atomically writes tasks, entities, knowledge, an approval, and a receipt) and git can't provide that.
  • No silent failures, anywhere. Every pipeline stage is an inspectable row with its error, attempt count, and backoff; every capture failure routes to repair or recovery instead of disappearing.

What I learned

  • Isolation belongs in the database, not the app — one missed filter should return nothing, not leak everything.
  • Adversarial structure beats better prompts: agents checking agents across model families caught what a single smarter model missed.
  • Schema-as-data pays off: knowledge categories are registry rows with JSON Schemas, so adding a ninth knowledge type is a data change, not a migration.
  • The wedge matters more than the platform: "post-meeting administration disappears" is measurable; "AI operating system" is not.

What's next

Customer zero is live piloting the wedge. Next: the exec's team joins the workspace (shared/private visibility, roles), desktop capture across meeting platforms, and eventually the whole company as shared operating memory.

Built With

Share this project:

Updates