Clay receives an intention or opportunity context
Technical architecture
A Cloudflare-first AI stack for opportunity fit.
Clay is built around one technical bet: opportunity fit improves when intent, personality, permissions, and partner context live in one typed system.
Hono validates the request at the Worker boundary
Opportunity services rank fit from intention and personality signals
Mastra can translate private context into consent-aware recommendations
Hyperdrive supplies the database connection boundary
Permission rules decide what can reach partners
01 / Stack
Six layers, each with a clear job.
The stack avoids a single monolith. Next owns the pitch, OpenAPI owns typed contracts, Cloudflare owns backend and deploy surfaces, and Mastra owns agent reasoning.
Landing
Next.js static pitching site
The public pitch is a static-export Next.js app seeded from the Exclay pitching pages and reframed around opportunity, intention, and personality fit.
Next.js 16React 19Tailwind CSS 4Static exportCloudflare Pages
Backend API
Cloudflare Workers, Hono, and OpenAPI
The backend stays close to the edge: Hono owns routing and validation, OpenAPI describes public contracts, and service code ranks opportunities from intention and personality context.
Cloudflare WorkersHonoOpenAPIZodTypeScript
AI runtime
Mastra opportunity agent
Mastra owns the Clay agent instructions, model routing, tool boundaries, and future workflows for translating private context into consent-aware opportunity recommendations.
Mastra agentsAI SDKTyped toolsGuardrailsEvaluations
Data
Hyperdrive database boundary
Cloudflare Hyperdrive is the Worker database connection boundary. Runtime code should use the binding instead of committing or reading raw database URLs.
HyperdrivePostgresWorker bindingsSecretsConnection pooling
Contracts
Typed route and schema discipline
Routes validate input with Zod and publish their expected shape through OpenAPI so clients and future packages can consume Clay without ad hoc transport logic.
Zod@hono/zod-openapiSwagger UIRedoclyStrict TypeScript
Deploy
Cloudflare-first delivery
The repo is shaped for Cloudflare Pages for the landing site and Cloudflare Workers for backend and agent endpoints, with room for R2, Queues, and partner services later.
Cloudflare PagesWorkersWranglerR2-readyQueues-ready
02 / Mastra toolchains
Mastra is the orchestration layer for agents, tools, workflows, memory, and evals.
The product should not hide intelligence inside screens or one-off API handlers. Mastra gives the team a place to compose agent behavior, trace decisions, test workflows, and evolve the assistant safely.
Input
Mobile context
Messages, preferences, consent, state, and product signals arrive through typed app boundaries.
Mastra
Agents + workflows
Agents decide, tools execute, workflows structure multi-step moments, and memory keeps continuity.
Output
Useful action
Clay streams a response, updates state, drafts a recommendation, or calls a partner API with permission.
Agents
Agents own opportunity reasoning: instructions, model routing, context policy, and decisions about when to ask, rank, recommend, or draft.
Opportunity agentContext policyModel routingGuardrails
Typed tools
Tools are explicit capabilities, not hidden prompt tricks. They can retrieve memory, call partner APIs, summarize a thread, rank options, or prepare a consented action.
Memory searchPartner lookupThread summaryAction draft
Workflows
Structured flows can handle multi-step product moments such as intention capture, opportunity ranking, partner qualification, consent, and introduction drafting.
CaptureSynthesizeRankConfirmAct
Memory
Memory is treated as product infrastructure. The agent layer decides what is short-term, what is durable, what should be forgotten, and what requires explicit consent.
Conversation historyWorking memorySemantic recallConsent rules
Streaming endpoints
Mastra endpoints can expose agent events, tool calls, and structured output without pushing opportunity reasoning into route handlers or UI screens.
Token streamTool eventsStructured outputBackend routes
Evals and observability
The system needs traces, prompt versions, regression datasets, and human review loops so the assistant gets safer and more useful as the product learns.
TracesEval setsPrompt versionsReview queues
03 / API integration
OpenAPI and Hono keep backend data boring and typed.
The backend should expose product APIs through route schemas and predictable contracts. That makes partner integrations and future generated clients easier to reason about.
OpenAPI contract layer
OpenAPI defines the shape of backend resources. API changes start at the contract instead of scattered fetch calls.
OpenAPI exportRedocly lintSwagger UITyped schemas
Opportunity service layer
Services should hold ranking and fit logic so Hono handlers stay focused on validation, auth, and HTTP response shape.
Intent signalsPersonality fitTimingPartner constraints
Hono service layer
Hono owns route handlers, middleware, validation, and Cloudflare Worker boundaries. Product APIs are exposed through OpenAPI so generated clients stay ahead of app code.
Route handlersZod inputOpenAPI routesCloudflare runtime
04 / Engineering principles
The stack is designed to protect product quality as Clay gets more intelligent.
The technical choices matter because personal context is sensitive. The system needs clear boundaries before it grows into partner experiences.
01
Opportunity-first, not chat-first
Chat can collect context, but the product value is better opportunity routing, introductions, recommendations, and partner fit.
02
Realtime by default
Intentions, recommendations, introductions, and partner workflows need event-aware primitives rather than request/response screens bolted together later.
03
AI outside UI components
UI renders state. Hooks coordinate flows. Services and agent runtimes own business logic, memory, tools, and model calls.
04
Permissioned context boundary
Clay can become a partner ecosystem only if private understanding stays protected and translated through explicit user consent.
05
Typed contracts everywhere
Zod validation, strict TypeScript, Hono route schemas, and OpenAPI contracts keep the app stable as the stack grows.
06
Static pitch, dynamic product
Investor and docs surfaces can deploy as static pages, while Cloudflare services and agents handle the living product experience.
05 / Technical roadmap
The architecture grows from chat wedge to personal context platform.
The current surface can stay narrow while the backend evolves toward richer memory, stricter permission rules, and partner-facing context APIs.
Now
Pitch and backend foundation
- Next landing app
- Cloudflare backend APIs
- Mastra agent endpoints
- Hyperdrive binding
Next
Opportunity context layer
- Intention capture
- Personality signals
- Permission rules
- Model evaluation loops
Later
Partner ecosystem
- Curated partner APIs
- Jobs, projects, and communities
- Cloudflare edge services
- Outcome feedback loops
Technical thesis
Clay is not another chatbot. It is a typed, permissioned context system with a Mastra-powered toolchain and chat as the first interface.
The moat is not a prompt. It is durable personal context, typed API contracts, realtime product state, careful consent boundaries, and the ability to turn understanding into useful actions without leaking private history.