What I build

Everything here is explained by concept and by example. The examples are invented for this page; the systems actually deployed for clients are not described, by decision. What they do and what they refuse is public; how they are built is not.

AI employees

An AI employee is not a chatbot. It owns a defined job from start to finish, works on the channel the team already uses, and stops for a person only where a decision belongs to a person.

Example: an on-call triage employee for a software team. A bug report arrives in the team's Slack channel. The employee reads it, tries to reproduce it against the staging build, attaches the logs and the failing request, files the issue with a severity, and links the last three related issues. If the report touches production data or a payment path, it pages a human before anything else. Nobody typed a prompt; the job description was written once.

What makes this an employee rather than a script: it understands language, decides the next safe step, uses tools, and finishes the job, inside limits that were agreed in advance.

AI agents

An AI agent is a single worker built for one task: it decides the next step, uses approved tools, completes the task within clear limits, and stops for a person at the gate. It is agentic AI at its smallest useful size. An employee is an agent with a job description, a channel and a schedule; a connector is how a process reaches an agent someone else runs.

Example: a dependency-upgrade agent. Once a week it reads the changelogs of the project's dependencies, bumps the safe ones, runs the test suite, opens one pull request per upgrade with the changelog excerpt, and leaves anything with a breaking change for a person. The procedure it follows is written down once and versioned, so the same job is done the same way every week.

The AI-native company

An AI-native company is what you get when every repeatable job has an AI employee and people sit only at the review points. The shape has four stations: work enters by itself, AI staff do the job, one person reviews, the result is delivered.

Example: a small software agency. A client request lands in the CRM. An intake employee turns it into a ticket with acceptance criteria. A planning employee writes the spec and the test list. A coding employee implements against those tests. A review employee runs the checks, scores the change against the team's checklist, and writes what it could not verify. A release employee prepares the deploy and the handover note. One engineer reads the scored change and approves the merge and the go-live. Nobody wrote a brief, chased a status, or assembled a handover.

What makes it possible is a runtime where each employee has its own workspace, its own written instructions and procedures, its tools (through MCP), and its own channels, and where work can run on a schedule as well as on demand. That is why the current runtime of choice is OpenClaw: it treats the employee, not the chat, as the unit of work, so a company can run staff-like agents with human approval gates instead of a row of chat windows. Which employees run where, and how many, is not published here.

MCP connectors

ChatGPT, Claude and Codex are generic. An MCP connector is a remote server that any of them can attach to, and it puts one company's process and rules inside the AI. The server does the enforcing: it serves the manual and the procedures, it checks each step, and it refuses work that skips one. So any AI that connects behaves like a trained employee of that company, in whichever client the team prefers.

Example: a code-review connector. A team attaches it to Claude Code. When a developer asks for a review, the server first serves the team's review checklist and the definition of done. It will not accept an approval until the test suite has actually run, it recomputes the coverage number instead of trusting the AI's claim, it refuses a "looks good" that has no filled checklist, and it records what was checked and what was not. Change a line after the review and the approval is void until the review runs again.

Why build connectors at all: without one, the process lives in someone's head and is re-typed into the chat every session, and it drifts every time. With one, the process is the server, and it is the same for every person and every client.

What is deliberately not published

The names of the employees, agents and connectors in production, how many there are, their architecture, their prompts, their clients, and the technology inside a delivered system. The journey counts them by year and never names them; that is the boundary. Ask in the audit for anything beyond it.