Guild

• 

• 

• 

• 

• 

Inspiration

Building software with AI still feels surprisingly fragmented.

A product brief may live in a document, architecture in a diagram, tasks in an issue tracker, designs in another tool, and implementation evidence inside pull requests. AI assistants usually operate in separate chat windows with incomplete context. Humans spend time copying information between tools, resolving conflicting output, and figuring out what changed.

We asked a simple question:

What if humans and AI teammates could build a software project together inside the same visible workspace?

That idea became Guild.

Guild is inspired by the flexibility of Whimsical, the multiplayer presence of Figma, the structured execution of Linear, and the capabilities of modern coding agents. The difference is that AI is not hidden behind a chat sidebar. AI Workers appear as actual project collaborators with defined roles, owned workspace regions, live progress, visible results, and accountable changes.

WebMCP was essential to this vision. Traditional browser agents have to interpret pages from pixels, DOM elements, and button labels. That approach is fragile and gives the agent very little understanding of the product’s actual domain.

With WebMCP, Guild can expose structured operations such as:

• Search the project canvas
• Read semantic relationships
• Create or update project artifacts
• Launch a team of AI Workers
• Monitor active Jobs
• Add precisely anchored feedback
• Publish immutable design revisions
• Record implementation evidence
• Stop, retry, or undo work

Guild is therefore not merely a web application that an agent can operate. It is a shared collaboration environment intentionally designed for people and agents to use together.

What it does

Guild is a multiplayer visual workspace where humans and locally running AI Workers build the same software project on one shared infinite canvas.

Instead of separating product thinking, architecture, design, implementation planning, feedback, and AI execution across disconnected applications, Guild keeps everything in one persistent project context.

One shared infinite canvas

Every Guild project has one multiplayer canvas with three creation modes.

Diagram mode

Diagram mode supports:

• Product requirements
• Brainstorming
• User journeys
• User flows
• System architecture
• Database architecture
• API relationships
• AI and agent architecture
• Decisions and impact maps

Task mode

Task mode supports:

• Engineering tasks
• Implementation plans
• Bugs
• Reviews
• Testing
• Launch checklists
• Project status

Task cards can contain Markdown descriptions, checklists, status, priority, labels, assignees, links, and semantic relationships.

Wireframe mode

Wireframe mode supports:

• Product screens
• Web and mobile interfaces
• Interface states
• User flows
• Low-fidelity prototypes
• Design annotations

These modes share the same canvas rather than creating separate diagram, task, and design applications.

Fifteen neutral canvas object types

Guild uses a small set of flexible visual primitives:

1. Shape
2. Sticky note
3. Text
4. Mind-map node
5. Table
6. Icon
7. Image
8. Link
9. Section
10. Annotation
11. Drawing
12. Task
13. Stack
14. Wireframe frame
15. Wireframe component

Semantic metadata gives these objects their project meaning. A shape can represent a service, database, API, requirement, decision, or AI system without requiring a separate renderer for every software concept.

Objects can be connected with relationships including:

• contains
• informs
• requires
• implements
• represents
• supports
• depends_on
• calls
• reads_from
• writes_to
• emits
• triggers
• verified_by
• affects
• blocks
• supersedes

This produces a visual software-project graph rather than a collection of unrelated cards.

Multiplayer collaboration

Multiple people can work in the same workspace in real time. Guild synchronizes:

• Cursor position
• Canvas viewport
• Current selection
• Editing state
• Comments
• Canvas changes
• Worker progress
• Runner availability
• Project activity

Every human, WebMCP, and Worker action is attributed in the activity history.

AI Workers with real responsibilities

An AI teammate in Guild is called a Worker.

Each Worker is configured through a Role Profile containing:

• Name and handle
• Project responsibility
• Instructions
• Local execution engine
• Owned canvas section
• Visual identity
• Available capabilities

For example, a Guild team could include:

• Product Lead
• Product Designer
• Systems Architect
• Research Engineer
• Backend Engineer
• Frontend Engineer
• Security and Evaluation Lead

A user can save these Role Profiles as a team and launch them together with one project brief.

Team Runs and Jobs

When the user selects Run Team, Guild deterministically creates one Job for each selected Role Profile.

Every Job receives:

• The same high-level brief
• Role-specific instructions
• Full bounded read context
• An owned section
• An atomically reserved canvas region
• Optional dependencies
• A short-lived assignment capability

Workers can understand the broader project, but they can modify only the objects and regions assigned to them.

Guild does not use a hidden planning model to decide which Workers should run. The user-selected team and its configuration determine the Job fan-out.

Visible parallel work

Workers do not disappear into background chat sessions. Guild shows:

• Which Worker is active
• Whether it uses Codex or Claude Code
• What it is currently doing
• Which canvas section it owns
• Which object it is working on
• Whether its Job is queued, running, blocked, failed, or completed
• What artifacts and comments it produced

If no compatible local Runner is available, the Job remains durably queued and the interface truthfully displays Waiting for Runner.

Canvas-native feedback and revision

Humans can annotate work directly on the Guild canvas or inside a hosted design preview.

Feedback may be attached to:

• An entire workspace
• A section
• A specific canvas object
• A precise point on a design
• A selected rectangle on a design
• An immutable screen revision

Annotations remain drafts until the user opens Review & Send. Guild groups the feedback by the responsible Worker and creates at most one revision Job per target Worker.

Every exact anchor is preserved, including the design revision, route, viewport, scroll position, point, or rectangle.

Immutable design revisions

Design Workers can publish hosted previews as immutable revisions.

Guild stores:

• Design-set identity
• Deployment identity
• Preview origin
• Screen names and routes
• Desktop and mobile viewports
• Related canvas objects
• Capture status
• Revision history
• Human approval decisions

Users can inspect a design inside Guild, compare revisions side by side or with a slider, request changes, and approve a specific immutable revision.

Implementation evidence

External implementation work can be reported back into Guild as bounded evidence:

• Repository
• Branch
• Commit
• Pull request
• Changed files
• Checks
• Preview deployment
• Related canvas objects
• Provenance

Guild carefully distinguishes a reported claim from independently verified information. A reachable link may be labeled Link verified, but Guild does not falsely claim that it executed a test or inspected a commit when it did not.

Reversible execution

Human actions, WebMCP calls, and Worker changes pass through the same command service.

Each accepted operation creates an attributable Change Set. Team Runs can be undone with conflict awareness, preserving unrelated human edits made afterward.

Jobs can also be stopped or retried. Stale Worker attempts are fenced so they cannot continue writing after cancellation or reassignment.

Guild's 25 WebMCP tools

Guild exposes 25 structured WebMCP tools through document.modelContext.registerTool.

These tools operate on the real application state. They are not mocked endpoints or a separate agent-only database.

Each tool has:

• A clear natural-language description
• A structured input schema
• Runtime validation
• Authentication and workspace authorization
• Abort support
• Audited execution
• Machine-readable results
• The same domain rules used by the human interface

Workspace discovery and understanding

1. list_workspaces

Lists the Guild workspaces available to the signed-in user.

This gives the browser agent an explicit starting point instead of forcing it to infer workspace names from navigation elements.

2. get_workspace_context

Reads bounded live project context, including:

• Workspace metadata
• Canvas objects
• Semantic relationships
• Role Profiles
• Saved teams
• Team Runs
• Runner state
• Placement guidance
• Color guidance

The response is intentionally bounded so an agent can understand the project without loading an unbounded canvas.

3. search_canvas

Searches visible content and semantic metadata inside one workspace.

An agent can find requirements, designs, decisions, implementation tasks, evidence, services, risks, or any other project artifact.

Canvas creation and collaboration

4. apply_canvas_changes

Applies up to 25 idempotent canvas commands in one operation.

Supported commands include:

• Create an object
• Update an object segment
• Move an object
• Resize an object
• Delete an object
• Create a semantic connector
• Delete a semantic connector

The tool uses revision checks, idempotency keys, server-side geometry validation, and a controlled color palette.

5. add_comment

Adds a comment to a workspace, section, or object and deterministically routes it based on ownership and mentions.

Comments can remain ordinary project notes or intentionally launch work through an explicit @Role, @team, or configured object owner.

6. dispatch_feedback_batch

Sends up to 50 exact canvas or hosted-design annotations in a single reviewed batch.

Guild groups annotations by target Worker, preserves every visual anchor, and creates no more than one revision Job or feedback delivery per target.

Team execution and control

7. run_ai_team

Queues a deterministic Team Run for a selected team and brief.

Guild Cloud schedules the Jobs, while actual AI execution happens through the paired local Guild Runner.

8. get_run_status

Returns the truthful state of a Team Run, including:

• Individual Jobs
• Dependencies
• Worker progress
• Failures
• Runner capacity
• Waiting-for-Runner state
• Completion information

9. get_runner_status

Returns the operational state of paired Guild Runners and their compatible local engines.

Sensitive Runner credentials and stored token hashes are never exposed.

10. stop_run

Cancels unfinished Jobs in a Team Run and fences all later writes from stale Worker attempts.

11. retry_job

Retries a failed Job using the same Role Profile and configured local engine.

Retries retain stable logical keys so Workers update intended artifacts instead of duplicating them.

12. undo_run

Performs a conflict-aware undo of a Team Run.

Changes created by the Run are reversed while later unrelated human edits are preserved.

Implementation-task workflows

13. list_implementation_tasks

Lists bounded task objects carrying implementation semantics.

This allows a browser agent to discover actionable engineering work without scraping task cards from the screen.

14. claim_task

Claims an implementation task for the signed-in human through Guild’s shared command service.

15. report_task_result

Records the result of a claimed task and creates an attributable Change Set.

Design publication and review

16. publish_design_preview

Publishes an immutable hosted-design revision.

The tool receives deployment identity, approved HTTPS origin, stable screen keys, routes, viewports, and related canvas objects. It never accepts arbitrary HTML or screenshot bytes.

17. get_design_set

Reads a design set, its screens, revision history, and current head revision.

18. get_design_revision_status

Reads publication and capture status for a specific design revision.

This lets the agent determine whether desktop and mobile captures are ready without visually polling the interface.

External agent workstreams

Guild distinguishes Runner-owned Jobs from external browser-agent workstreams. External activity is reported, not falsely presented as locally observed execution.

19. register_workstream

Registers a stable external workstream with a responsibility, engine identity, and logical key.

20. report_workstream_update

Records a monotonic progress update with sequence and timing information.

Out-of-order or stale updates cannot overwrite newer state.

21. complete_workstream

Marks an external workstream as completed, blocked, or cancelled.

22. get_workstream_feedback

Retrieves pending visual feedback addressed to a particular external workstream.

23. acknowledge_workstream_feedback

Acknowledges that a targeted feedback item has been received.

Acknowledgement is distinct from claiming the requested work has been completed.

Implementation evidence

24. report_implementation_evidence

Reports bounded implementation evidence such as files, checks, commits, pull requests, and preview links.

All claims remain explicitly labeled as Reported unless Guild performs a separate permitted verification.

25. list_implementation_evidence

Lists the implementation evidence associated with a workspace, including provenance and verification labels.

The assignment-scoped local MCP

Guild deliberately separates its browser WebMCP tools from the tools available to local AI Workers.

The 25 WebMCP tools allow a signed-in browser agent to control and collaborate with the Guild application.

A Worker launched through Guild Runner receives only seven assignment-scoped MCP tools:

1. get_workspace_context
2. search_canvas
3. apply_canvas_changes
4. add_comment
5. publish_design_preview
6. get_assignment_feedback
7. report_progress

The Worker does not receive arbitrary access to every Guild operation. The local MCP bridge automatically binds requests to the active Job, Worker identity, Work Claim, Reserved Region, attempt number, and short-lived capability.

This means a Worker cannot choose another workspace ID, impersonate another Job, or expand its own permissions.

get_workspace_context

Returns bounded shared context, current revisions, semantic relationships, assignment identity, and continuation information.

Workers are instructed to read this context before writing.

search_canvas

Finds additional objects or relationships when the bounded initial context does not include what the Worker needs.

apply_canvas_changes

Allows the Worker to create or modify artifacts only inside its Work Claim and Reserved Region.

Out-of-region, colliding, stale-revision, and stale-attempt writes are rejected server-side.

add_comment

Creates an assignment-attributed progress, result, review, or blocker comment.

Worker-authored comments cannot mention another Worker or secretly schedule more work.

publish_design_preview

Allows a design Worker to publish an immutable hosted preview with stable design and screen identities.

The Worker provides deployment metadata rather than injecting HTML into Guild.

get_assignment_feedback

Returns the complete reviewed feedback packet for a revision Job, including:

• Overall human instruction
• Every exact annotation
• Canvas or design anchors
• Immutable revision identity
• Optional bounded image crop

report_progress

Publishes concise progress using controlled phases:

• reading_context
• working
• writing
• finishing

Guild and the Runner—not the model—control authoritative Job states such as queued, running, failed, cancelled, and completed.

How we built it

Guild uses a split architecture with a hosted coordination layer and a local execution layer.

Human + WebMCP browser agent
              │
              ▼
Next.js 16.3.4 application
              │
              ├── WorkOS AuthKit
              │
              ▼
Convex realtime control plane
              │
              ├── Canvas and semantic graph
              ├── Presence and comments
              ├── Teams, Runs, and Jobs
              ├── Claims and reservations
              ├── Revisions and Change Sets
              └── WebMCP service adapter
              │
       Outbound HTTPS polling
              │
              ▼
Guild Runner on the user's Mac
          ┌───┴────┐
          ▼        ▼
     Codex CLI  Claude Code
          │
          ▼
Assignment-scoped local MCP
          │
          ▼
Validated visible canvas changes

Frontend

The frontend is built with:

• Next.js 16.3.4
• React 19
• TypeScript
• Tailwind CSS
• React Flow
• Zustand

React Flow powers the infinite canvas, selection, dragging, resizing, connections, viewport controls, and minimap.

Zustand manages responsive local interaction state, while durable project state comes from Convex.

Authentication

Guild uses WorkOS AuthKit for authentication.

Authenticated membership checks protect workspace data. Runner endpoints intentionally use a separate authorization path based on pairing tokens and short-lived assignment capabilities rather than browser cookies.

Realtime data and scheduling

Convex stores and synchronizes:

• Users and workspaces
• Memberships
• Canvas objects and edges
• Revisions
• Comments
• Activity
• Presence
• Role Profiles
• Teams
• Team Runs
• Jobs
• Runners and pairings
• Work Claims
• Reserved Regions
• Leases
• Capabilities
• Change Sets
• Design revisions
• External workstreams
• Implementation evidence

Guild Cloud stores state, schedules work, and validates mutations. It performs no model inference.

Local AI execution

The macOS Guild Runner:

• Pairs through a device-code flow
• Stores its long-lived token in macOS Keychain
• Detects installed Codex and Claude Code clients
• Verifies local client readiness
• Polls for compatible Jobs
• Respects configured concurrency
• Renews Job leases
• Launches subprocesses without a shell
• Uses a minimal allowlisted environment
• Applies output and time limits
• Redacts known secrets
• Supports cancellation
• Reports progress and results

The user’s Codex and Claude subscription credentials remain under the control of their official local clients. Guild never asks for or stores:

• OpenAI API keys
• Anthropic API keys
• Codex login files
• Claude Code login files
• Browser cookies
• Subscription OAuth tokens
• Local keychain credentials

Shared command service

The human interface, WebMCP tools, Worker MCP tools, and undo engine all use the same command service.

This ensures consistent:

• Authorization
• Revision checks
• Geometry validation
• Idempotency
• Attribution
• Activity history
• Conflict handling
• Undo behavior

A WebMCP-created object is therefore a real Guild object, immediately visible to human collaborators.

Collision-free parallel work

A Team Run reserves every Worker region atomically.

Each Worker receives a fixed cell in a new Run zone. Guild controls final placement using:

• Fixed reservation dimensions
• Outer padding
• A placement grid
• Child-object padding
• Server-side collision checks
• Parent-section ownership
• Stable logical keys

Workers can suggest content and size, but the command service determines safe geometry.

Stale-write protection

Every active Worker write is checked against:

• Workspace membership
• Job identity
• Attempt number
• Runner lease
• Fencing token
• Assignment capability
• Work Claim
• Reserved Region
• Object revision

If a Job is stopped, retried, or reassigned, its previous attempt can no longer mutate the project.

Idempotency and undo

Every mutating operation carries an idempotency key.

A repeated request returns the existing result instead of duplicating work. Stable logical object keys also allow retried Workers to update their prior artifacts.

Accepted mutations are grouped into Change Sets. Conflict-aware undo reverses the intended changes without erasing newer unrelated edits.

Challenges we ran into

Making WebMCP genuinely useful

The easiest implementation would have been a few shallow wrapper tools around existing buttons. That would technically demonstrate WebMCP but would not create a meaningfully better product.

We instead designed 25 tools around Guild’s actual domain: workspaces, semantic canvas objects, teams, Jobs, Workers, revisions, visual feedback, and evidence.

The difficult part was choosing operations that were powerful enough for meaningful work while remaining understandable, bounded, and safe.

Giving humans and agents one source of truth

A separate agent backend would make it difficult for users to understand what happened.

We routed human actions, WebMCP calls, Worker writes, and undo through the same command layer. This required more careful engineering, but it means every participant works with the same visible project state.

Running AI locally without taking custody of credentials

We wanted Guild to use the AI clients people already trust and pay for.

That meant separating hosted coordination from local inference. Pairing, Keychain storage, token exchange, capability scoping, subprocess isolation, cancellation, and redaction all had to work together without exposing local credentials to Guild Cloud.

Coordinating concurrent Workers

Parallel Workers can create race conditions:

• Editing the same object
• Placing objects on top of one another
• Writing outside their responsibility
• Continuing after cancellation
• Duplicating results after retry

Guild addresses these problems with Work Claims, Reserved Regions, revision checks, leases, fencing tokens, idempotency keys, and server-controlled placement.

Preserving human control

AI activity is hard to trust when it is invisible or irreversible.

Guild makes Worker identity, engine, progress, target, artifacts, feedback, and evidence visible. Feedback remains a local draft until explicitly sent. Design revisions are immutable. Changes are attributable and reversible.

Representing visual feedback precisely

A comment such as “fix this section” is ambiguous when a design contains several screens and versions.

Guild persists the exact design revision, route, viewport, scroll position, and normalized point or rectangle. Old comments remain attached to the version on which they were created.

Reporting evidence honestly

An agent may claim that tests passed or that a deployment is ready. Guild must not silently convert that report into verified truth.

We built explicit provenance states such as Reported, Link verified, and Unavailable. Reachability verification confirms only that a permitted public link resolves.

Keeping a complex product coherent

Guild combines a canvas, task system, multiplayer presence, local process, Job scheduler, design-review system, evidence model, and WebMCP interface.

The central design decision was to keep everything anchored to one workspace graph and one command service. That gave the product a consistent mental model despite the number of subsystems.

Accomplishments that we're proud of

We are proud that Guild is a working product rather than a technical WebMCP wrapper.

The completed system includes:

• One realtime multiplayer infinite canvas
• Three creation modes
• Fifteen neutral object types
• Semantic project relationships
• Role Profiles and saved teams
• Deterministic Team Runs
• Concurrent Codex and Claude Workers
• A paired macOS Guild Runner
• Twenty-five browser WebMCP tools
• Seven assignment-scoped Worker MCP tools
• Work Claims and Reserved Regions
• Collision-resistant object placement
• Leases, attempt numbers, and fencing tokens
• Idempotent commands
• Conflict-aware undo
• Live Worker identity, progress, and results
• Canvas-native comments
• Anchored design feedback
• Grouped feedback review and dispatch
• Immutable design revisions
• Revision comparison and human approval
• External workstream reporting
• Bounded implementation evidence
• Decision memory and activity history
• WorkOS authentication
• Convex realtime persistence
• A production Vercel deployment

The Cinemaverse demonstration

We tested Guild through a complete software-project scenario called Cinemaverse.

Six specialized AI roles worked inside separate owned canvas regions:

• Product and Visual Designer
• Agentic Systems Architect
• Search and Evidence Engineer
• Backend and Data Engineer
• Canvas and Frontend Engineer
• QA, Security, and Evaluation Lead

Together they produced detailed project artifacts covering product requirements, system architecture, visual design, research, data modeling, frontend behavior, implementation evidence, and evaluation.

A human then:

1. Inspected the generated artifacts
2. Opened their complete Markdown content
3. Added one architecture annotation
4. Added two exact hosted-design annotations
5. Reviewed feedback grouped by Worker
6. Added an overall revision instruction
7. Dispatched one feedback batch
8. Observed revised output
9. Compared immutable design versions
10. Approved the selected revision

The demonstration made Guild itself the visible product throughout the collaboration.

Verification

The latest complete local quality gate passed:

• Formatting
• Zero-warning ESLint
• Strict TypeScript
• Protocol build and typecheck
• Runner typecheck and production build
• 221 application tests
• 42 Runner tests
• Next.js production build
• Public desktop and mobile browser checks

Production verification also covered:

• Authentication
• Canvas persistence
• Native WebMCP registration and execution
• Realtime collaboration
• Concurrent Codex and Claude Jobs
• Separate Worker reservations
• Collision rejection
• Stop and retry
• Stale-attempt fencing
• Conflict-aware undo
• Design revision workflows
• Visual feedback
• Implementation evidence

What we learned

Agents need semantic interfaces

Agents perform better when applications expose meaningful operations instead of forcing them to imitate clicks.

run_ai_team communicates far more intent than “click the button near the bottom of the sidebar.”

WebMCP is more than browser automation

WebMCP allowed us to describe what Guild means, not merely what its interface looks like.

This transformed WebMCP from an automation convenience into part of the product architecture.

Shared state creates trust

When agents operate on a separate hidden copy of project state, humans cannot easily understand or correct their work.

Guild’s shared command layer ensures that agent actions become visible, attributed project events.

Boundaries improve useful autonomy

Workers became more reliable when given:

• Clear roles
• Full bounded read context
• Owned sections
• Reserved space
• Limited tools
• Stable logical keys
• Explicit completion rules

Giving every Worker unrestricted access would have made the system less collaborative, not more.

Visibility is part of correctness

A background task can succeed technically while still creating a poor product experience.

People need to know:

• Who is working
• What they are doing
• Where they are working
• What changed
• What evidence exists
• What decision is required

Guild treats that visibility as product state rather than animation.

Reported evidence and verified evidence are different

Agent-generated claims need clear provenance. A trustworthy system should communicate exactly what it knows, what an agent reported, and what it independently verified.

Local and hosted infrastructure can complement each other

The cloud is effective for collaboration, persistence, authorization, and scheduling. Local AI clients are effective for authenticated execution.

Keeping those responsibilities separate gave Guild a strong privacy boundary without sacrificing a coherent web experience.

Human approval should be explicit

Drafting a comment should not silently launch an expensive or consequential AI task.

Guild separates drafting, reviewing, sending, revising, and approving so the human remains in control of when work begins and which version becomes accepted.

What's next for Guild

Guild’s next step is to deepen the connection between visual project planning and implementation while preserving explicit consent, scoped authority, and visible provenance.

Consent-based repository execution

Today, Guild Workers create and modify Guild canvas artifacts. A future repository workflow could add:

• Explicit directory consent
• Isolated per-Job worktrees
• File-level ownership
• Diff review
• Test-result capture
• Merge-conflict handling
• Human approval before integration

Semantic impact analysis

Guild’s project graph could trace the impact of a changed requirement across:

• User flows
• Designs
• Services
• APIs
• Database fields
• Implementation tasks
• Tests
• Security assumptions

A Worker could then propose updates to the affected artifacts for human review.

Reusable project templates

Teams could start with role configurations and canvas structures designed for:

• SaaS applications
• Mobile products
• AI agents
• APIs
• Internal tools
• E-commerce systems

Additional local AI clients

The Runner architecture can support more official authenticated CLI clients through explicit adapters without turning Guild Cloud into a hosted model proxy.

Larger workspaces

For projects beyond the current active-canvas target, Guild could add:

• Spatial indexes
• Viewport-based loading
• Section-based subscriptions
• Spatial sharding
• More advanced canvas search

WebMCP evaluations

We want to build repeatable evaluations that measure:

• Tool discovery
• Task completion
• Mutation accuracy
• Recovery from invalid input
• Permission-boundary enforcement
• Idempotent replay
• Safe cancellation
• Human-agent handoff quality

A broader agent-native collaboration protocol

The long-term vision is bigger than adding AI features to project-management software.

We believe web applications can become shared environments where people and agents:

• Understand the same context
• Use interfaces designed for their respective strengths
• Collaborate through explicit responsibilities
• Produce visible and attributable work
• Preserve human authority
• Recover safely from mistakes

Guild is our exploration of what the open web looks like when humans and agents can genuinely build together.

Built With

• bun
• claude-code
• codex
• codex-cli
• convex
• github
• jose
• model-context-protocol-sdk
• next.js-16.3.4
• node.js
• playwright
• react-19
• react-flow
• tailwind-css
• typescript
• vercel
• vitest
• webmcp
• workos-authkit
• zod
• zustand