MV
  • Home
  • Work
  • Notes
  • Uses
  • Contact
  • ⌘K

Mahesh Vyas — AI/ML Engineer

Co-Founder, Skillwyn Labs

2026.08.10 · 16:40 IST

  • GitHub
  • LinkedIn
  • X
  • Instagram
  • Email
← All work

Theta

SHIPPED

Independent

Production AI agent platform — plans, acts, and verifies its own work

Open live →

Free-tier host — the first request wakes the server and can take ~60s.

The problem

Getting a computer to actually finish a multi-step task across your email, your notes, and the web still means doing every step by hand.

What I built

Theta plans a natural-language task, then executes it — calling tools, driving a real browser with Playwright, and operating Gmail and Notion through a single MCP tool layer with dynamic tool discovery. Anything consequential stops at a human approval gate before it happens, and every write is read back to confirm it landed. Successful runs compile into deterministic playbooks that replay later with no LLM calls at all.

PythonClaude LLMMCPPlaywrightNotion APIGmail API

Gmail

  • ·Search and read emails and threads
  • ·Draft replies in context
  • ·Send — gated behind mandatory human approval, always

Notion

  • ·Search and read pages and databases
  • ·Create pages, update pages and properties
  • ·Verify every write by reading it back

Safety layer

  • ·Human approval before consequential actions
  • ·Credential refusal
  • ·Prompt-injection protection on untrusted email and Notion content

Playbooks & schedules

  • ·Successful runs compile into deterministic replays
  • ·Schedules run playbooks unattended at 0 LLM calls
  • ·Safe failure handling and browser-conflict avoidance

Architecture

  1. in / out

    Natural-language task

    “Find the renewal thread and draft a reply.”

    ↓
  2. reasoning

    Planner — Claude

    Decomposes the task and selects tools. The only step that reasons.

    ↓
  3. tools

    MCP tool layer

    One layer, dynamic tool discovery at runtime.

    ↓
  4. tools

    Playwright

    Drives a real browser.

    tools

    Gmail API

    Search, read, draft, send.

    tools

    Notion API

    Pages, databases, properties.

    ↓
  5. human

    Approval gate

    Consequential actions stop here. Gmail sends always require approval — including on a schedule.

    ↓
  6. gate

    Write verifier

    Re-reads every write and confirms the end state. A 200 response is not treated as proof.

    ↓
  7. state

    Playbook compiler

    A successful run compiles into a deterministic replay.

    state

    Scheduler

    Replays run unattended at 0 LLM calls. Gmail sends are excluded.

Across every step

  • Prompt-injection protection

    Email and Notion content is untrusted input, not instructions.

  • Credential refusal

    The agent will not handle secrets.

reasoningtoolsstategatehuman
Theta architecture. One task in, one verified result out. The model plans; the MCP layer acts; nothing irreversible happens without a human, and nothing is reported as done until it has been read back.

Hard decisions & trade-offs

The agent verifies its own writes instead of trusting API responses

Chose
After every write, Theta re-reads the resource and confirms the change is actually there before reporting success.
Rejected
Treating a 200 response as proof the write landed — the default, and one fewer round trip per action.
Why
A success response means the request was accepted, not that the end state is what the agent intended. Partial writes, silently dropped properties, and permission-scoped no-ops all return 200. An agent that reports success it never confirmed is worse than one that fails loudly, because the human stops checking. The extra read is cheap; a confidently wrong agent is not.

Gmail sends are deliberately excluded from playbook replay

Chose
Playbooks replay everything except Gmail sends. Those stay approval-gated even when the playbook runs on an unattended schedule.
Rejected
Full replay fidelity — recording an approved send once and letting the schedule repeat it at 0 LLM calls like every other step.
Why
Replay's whole value is removing the human from the loop, which is exactly what you must not do for an irreversible action addressed to another person. Approving a send once is not approving it every morning at 9am forever. The inconsistency is the point: the one step that can't be undone is the one step that keeps its gate.

One MCP tool layer with dynamic discovery, not per-service integrations

Chose
Gmail, Notion and the browser all sit behind a single MCP layer the agent discovers tools from at runtime.
Rejected
Hand-wiring each service into the agent's prompt and control flow separately.
Why
Per-service integration means every new capability edits the agent itself, and the prompt grows until tool selection degrades. Discovery through one layer means adding a service doesn't touch the reasoning code, and the safety and verification rules apply uniformly instead of being re-implemented per integration.

Verified numbers

tests passing
302
self-test
14/14
first run vs. playbook replay
27.2s → 5.3s
LLM calls on replay
6 → 0
Open Theta →All work →Get in touch →