Case study
Relaystack
Contributed as a full-stack engineer on a three-person team building AI operators that execute multi-step work instead of stopping at chatbot replies.
- 3
- engineers on the team
- ~8 mo
- tenure, Jan to Aug 2026
- Beta
- Social Growth Manager live
- User goal: A plain-language goal from the user, for example a lead-generation or posting task.
- Skill router: Parses the goal and dispatches it to the right domain-specific skill module.
- Lead gen: Skill module for lead generation: finds fits and drafts introductions.
- Social growth: Skill module for social media: plans and drafts posts.
- Career coach: Skill module for career work: finds roles and tailors applications.
- Memory: Redis holds session state. PostgreSQL holds longer-term context about the user.
- Tool calls: OpenAI tool calling runs the multi-step pipeline, then stops for approval.
Context
Relaystack is an AI-operator product. Users switch on a specialist, answer setup questions once, and the operator carries out the job in the open — then stops for approval before anything is posted or sent. The public product includes Social Growth Manager (beta), Lead Generator, and Career Operator.
Problem
Most AI tools generate advice and leave the actual work with the user. The product needed workflow experiences that plan, draft, and queue real outputs across social, outreach, and career tasks, while keeping a human in control of what goes out.
My role
I joined a small engineering team of three as a full-stack engineer for about eight months. I did not build the entire platform. I contributed to the operator experiences, shared frontend/API contracts, and the execution layer that turns a goal into a sequence of tool calls rather than a single chat reply.
Challenge
The hard part is reliability: routing a goal to the right operator, keeping session and longer-term context, and running multi-step tool-calling pipelines without losing state or producing unreviewable output. The work had to stay testable and recoverable inside a small team moving quickly.
Approach
I worked across the TypeScript/Node.js skill-routing path, Redis session state and PostgreSQL longer-term context, OpenAI tool calling for multi-step pipelines, and shared Zod schemas so frontend and API layers used the same contracts. On the product side I helped shape operator UX for Social Growth Manager, Lead Generator, and Career Operator.
Outcome
Social Growth Manager is live in public beta. Lead Generator and Career Operator are still being built. Relaystack publicly describes itself as a small team of AI operators that finish the job and wait for a yes.
Decisions
Execute, then wait for approval
Operators do the work in the open, then stop. Nothing posts or sends by default. That constraint shaped both the workflow UI and the execution pipeline: every consequential step has to be inspectable.
Shared contracts over ad-hoc payloads
Shared Zod schemas across frontend and API reduced mismatch bugs in a three-person team. The trade-off is more upfront schema work in exchange for safer iteration on operator features.
Two-tier memory
Redis holds what the operator is doing now. PostgreSQL holds longer-term context about the user. That split keeps session work fast without treating every request as a cold start.
What shipped
Social Growth Manager
Plans, writes, and queues posts in the user’s voice, then waits for approval. This is the operator currently in public beta.
Lead Generator
Finds people who fit, checks they are real, and drafts intros. Publicly listed as in development.
Career Operator
Finds roles, tailors applications, and prepares outreach. Publicly listed as in development.
Stack
TypeScript · Node.js · React · Redis · PostgreSQL · OpenAI API · Zod
The work was about shipping AI product inside a small team: shared contracts, inspectable execution, and user-facing operator flows — not a solo platform rewrite.