Glossary

Engineer. An AI teammate you hired. Each has a name, a role, a model, optional persona and working conventions, optional skills, a meeting voice, and a status (ACTIVE or PAUSED). Every portal chat, Slack thread, delivery step, review and meeting it works on is a separate session. An engineer's long-term memory is shared across its work and is meant for team-level facts only, not what one person said in a private chat.

Role. What kind of engineer it is. The roles in the library:

• Backend Engineer: implements backend tickets end to end (code, tests, PR).
• Frontend Engineer: builds UI against the design, wires it to APIs, tests, opens a PR.
• Fullstack Engineer: works across the stack (API, data, UI and tests) in one PR.
• Mobile Engineer: iOS and Android features, native or cross-platform, matching your stack.
• Data Engineer: pipelines, ETL/ELT, SQL and dbt, schema migrations, data-quality checks.
• Code Reviewer: reviews pull requests for correctness, security and maintainability.
• QA Engineer: test plans from acceptance criteria; writes and runs tests; verifies features.
• Engineering Lead: plans and decomposes work, routes it to the right specialists, reports.
• DevOps Engineer: CI failure triage (reads the failing job's log), dependency updates, CI config and release prep. Deploys when AWS, Cloudflare, Netlify or Render is connected.
• Site Reliability Engineer (SRE): incidents, logs and alerts, post-deploy verification, postmortems, runbooks. Needs monitoring to work from: connect Sentry, Grafana Cloud or PagerDuty (Integrations → Cloud & Operations) and it can be hired.
• Security Engineer: dependency/CVE exposure, secret leaks, injection and authz flaws; PR security reviews and remediation PRs.
• Software Architect: design docs and ADRs grounded in your codebase.
• Product Analyst: turns requirements into epics, stories and acceptance criteria.
• UX Designer: user flows, screen-by-screen specs, states and UX acceptance criteria, from the PRD and your design system. Limited: reads Figma when connected, but doesn't draw in it.
• Technical Writer (docs engineer): keeps READMEs, API docs, changelogs and runbooks true to the code; opens docs PRs.
• Delivery Manager: standup and meeting summaries, status reports, risks, delivery reports.

Some roles are Limited for now (the catalog card says what's missing): QA has no browser or running app; Security has no scanners; Data reads only databases you connect; Mobile has no build tools or simulators; DevOps deploys only where a cloud provider is connected. They're hireable and useful within those limits. A delivery's Deploy step runs when a cloud provider is connected and that environment is described (Integrations → Environments); Verify runs when monitoring is connected. Otherwise the delivery waits there for a person to do it and release the step.

Workspaces on the Enterprise tier can also create custom roles with their own system prompt.

Workspace. Your organisation's isolated space: its engineers, integrations, workflows, deliveries, members, usage and billing. You can belong to more than one; switch with the organisation switcher at the bottom of the sidebar.

Member roles.

• Owner: everything an admin can do, plus exporting data, offboarding the workspace, restoring someone whose access was paused by the guardrails, and anything marked owner-only.
• Admin: hire, edit, pause and retire engineers; connect integrations; edit workflows; start deliveries from the portal; call off deliveries; answer engineers' questions and release human steps in the portal; manage members; see and manage Billing and Monitoring; set rates on Insights; set the confidence threshold, escalation policy and channel routes.
• Member: chat with engineers (portal, Slack, DMs); start deliveries (portal and Slack) and resume blocked ones; interview candidates before hire; view workflows, deliveries, Inbox, skills, integrations and Insights (without money figures). A member can act on a human step they own or back up. Members can't see Billing or Monitoring.

"Owner or admin" is sometimes called a manager in this guide.

Chat vs delivery. A chat is a conversation with one engineer (portal chat, a Slack thread, or a DM). The engineer does what you ask in that conversation, which can include writing code and opening a PR. A delivery (shown on the Deliveries page; called a "task" in some places) is a piece of work that runs through a workflow, step by step, with handoffs between engineers and people, and a timeline you can follow.

Workflow. The pipeline a delivery runs through: an ordered set of steps with routing between them. A workspace can have several. One is the default, used when a delivery doesn't name one.

Step. One stage of a workflow. Each step has an action (Plan, Implement, Review, QA, Merge gate, Done, Custom, and others), is performed by an agent role or a person (a human gate), and has routes for on success, on failure and, for some actions, on skip.

Human step / human gate. A step a person does or approves (for example "Human merge", "Scope sign-off", "Production deploy approval", or a QA or code review you want a person to do). The delivery waits there, shown as WAITING_HUMAN ("waiting on a person"), until someone releases it or sends it back.

Routing by discipline ("auto"). An Implement, Review or Custom step can be set to Auto-route by task instead of a fixed role. The Plan step decides which discipline the task needs (backend, frontend, mobile, data, fullstack…) and the step goes to that kind of engineer. If that discipline isn't hired, the step waits for a person instead of failing. Work spanning several disciplines can be split into sub-tasks.

Named engineers. Optionally, pick which engineer takes a step: as a default on the workflow ("Default engineer"), or for one delivery when you start it. Without names, routing works by role as normal.

Step owner and backup. A human step can be given to a named person plus an optional backup. When the step before finishes, the owner is told (Slack DM and a mention in the delivery thread, or email if they're not on Slack). Without an owner, any admin can release it.

Credits. The unit work is paid in. Engineer work (chats, delivery steps, reviews), meetings and pre-hire interviews use credits.

Plan. A monthly subscription (paid in naira through Paystack) that includes a number of credits each month and an engineer limit. A workspace needs a plan, or a free trial, for its engineers to work.

Top-up. Extra credits bought as a one-off bundle. Top-up credits never expire.

Trial. A free trial of a plan, once per workspace, with a set number of credits.

Inbox. The page listing engineers' open questions and everything waiting on a person, plus the confidence threshold, escalation policy and channel routes.

Channel routes. Rules for which Slack channel engineers post progress, handoffs, requests for help and approvals to, for the whole workspace or per repo.

Escalation. What happens when a question or approval to a person goes unanswered: hold, nudge a channel, auto-approve or auto-deny, after a timeout you set.

Skills. Reusable instructions an engineer applies when relevant (house style, review checklists, domain rules). Some come with each role; you can attach more and write your own.

Integrations. Connections to the tools engineers work in: GitHub, GitLab, Bitbucket, Slack, Jira, Confluence, Google Drive, Notion and Figma, plus Cloud & operations tools (Sentry, Grafana Cloud, PagerDuty, AWS, Cloudflare, Netlify, Render, Supabase, Neon, PlanetScale, MotherDuck, your own Postgres/MySQL databases, and any custom MCP server).