# What I build (/docs/about/what-i-build) --- type: Document title: What I build description: AI employees, MCP connectors, skills, custom agents, and the AI-native company, explained by concept with software-delivery examples. status: stable order: 2 generated: { by: "process:claude-code", at: 2026-08-27T09:00:00Z } verified: - { by: "human:rrizwan98", at: 2026-08-28T14:00:00Z } ksor: audience: [public] owner: human:rrizwan98 approval: { by: "human:rrizwan98", at: 2026-08-27T09:30:00Z } trust_tier: human-reviewed build_id: sha256:d9f989bee8fa4c15cf0f7f1572f9e9a18305ef4e2ce0c3cfb6a5a421ead6dc1d dirty: true --- 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. ## 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, its own skills, 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 skills, 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. ## Skills A skill is a written procedure the AI reads before it acts: the steps in order, the checks before and after, what a complete result looks like. It is kept verbatim and versioned, so the same job is done the same way by every agent in every runtime, and a change to the procedure is a change to one file. **Example: a database-migration skill.** The skill lists the order (back up, write the migration, write the rollback, run on a copy, compare row counts, run on staging, run on production inside a maintenance window), the checks at each step, and the two conditions under which the agent must stop and ask a person. An agent that reads it first cannot "forget the rollback", because the skill is the checklist. ## Custom agents An agent is a single worker built for one task: it decides the next step, uses approved tools, and completes the task within clear limits. 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. ## What is deliberately not published The names of the employees and connectors in production, how many there are, their architecture, their prompts, their clients, and the technology inside a delivered system. The [journey](../journey/2026-ai-employees-and-connectors.md) names the connectors that are live and what each refuses; that is the boundary. Ask in the [audit](contact.md) for anything beyond it.