An AI employee platform: hire roles, not build workflows

An AI employee platform is a hiring decision, not a software rollout

When I say AI employee platform, I mean one specific thing. It is a place where a small team hires roles that do complete jobs. The work lands in the tools the team already runs. The risky steps stop and wait until a person says go.

The buyer I have in mind does not run an enterprise transformation office. The buyer is a founder, or a team of four people covering nine jobs. In a team like that, "someone should follow up on that" means nobody follows up. There is no spare person.

Such a team does not need another tool to operate. It needs the missing colleague. And that colleague has to arrive already knowing the job, because nobody has spare weeks to set up more software either.

I define the term itself in AI employees. This post is about the platform around them, and what it has to do for a team where one person reviews everything.

An employee owns a job, a chatbot answers a question

A chatbot's work ends when the conversation ends. Whatever it produced, you still have to finish the job by hand. You paste the draft into the email. You turn the answer into a ticket. You apply the suggestion to the codebase. That last step takes the time a small team does not have. So a chatbot subscription rarely changes anyone's week.

An AI employee starts from a job instead of a message. In aldena, each role ships with its limits already set. Vera, the business analyst, asks clarifying questions before writing a line of the spec. Magnus, the engineering manager, hands out the build work, runs the review loop, and opens the pull request. He never writes code himself. Orion, the bug fixer, reproduces the failure first, then fixes it and locks the fix in with a regression test.

There are more roles like that on the agent roster. You hire the ones a project needs instead of writing personas from scratch. Those limits are what make a hand-off mean something. When the analyst is done, a spec with acceptance criteria exists, and the next role picks it up.

Clawployees makes the same distinction with an imaginary standup. Named agents report the work they finished overnight, and every item is flagged for human approval. I like that framing because of where it puts the emphasis. What counts is what exists in the morning that did not exist the night before. Chat quality does not matter here.

The work has to land in the tools you already run

Every platform looks good inside its own app. The question that separates a demo from a hire is where the work sits when the run finishes. If the answer is a chat transcript, someone on your team now has to move that text into the real systems by hand. On a four-person team, that someone is you.

In aldena, integrations connect per room. A room is one private workspace with its own server and its own connected accounts. You add only what that project needs. GitHub, Linear, and Google Drive are three of the options. Engineering work arrives as a real pull request against your default branch, with the diff, the test results, and the reasoning attached. The backlog goes into the tracker you already run. Documents land in Drive.

Nothing about your review habits has to change. You read pull requests where you have always read pull requests. That is the bar I hold the product to. Once the work is delivered, you can stay in your own tools.

Where human review has to sit

For a small team the scarce resource is review capacity. Compute and money are easier to find. There is one morning and one person. So review cannot mean reading every step of everything an agent does. It has to sit where a mistake gets expensive. That means the merge, the ticket that turns into a week of work, and the message a customer reads.

In aldena you control that placement with a setting. Every tool an agent can call carries one of three policies you set per room: allow, ask, or deny. Reading files and running the test suite can run free. Writes, shell commands, and anything inside your connected accounts can stop first. The run pauses and shows you the exact call it wants to make before it happens. A paused run keeps its state, so you can answer after lunch and it continues from the same step.

Two gates come already set up. The delivery role opens the pull request and stops there, because its instructions tell it that the open request is your review gate. Merging is a write tool too, so it stops for you unless you set it to allow. And Atlas, the scrum master, shows you the whole proposed backlog first. It waits for your explicit go-ahead before it creates a single ticket in your tracker.

Two more details matter most at small scale. First, asking a person a question is itself a tool, and it is the one tool an agent cannot lose. When an agent finds something unclear, it asks instead of guessing. Second, answering "always allow" saves that policy. Trust widens one decision at a time, and you are never asked the same question twice. Autonomy works the same way with a human hire. It is earned, it is specific, and you can take it back.

A normal morning looks like this. I open a room and find three things waiting. There is a pull request from Magnus with the tests passing. There is a proposed backlog from Atlas that has not touched the tracker yet. And there is one paused run where Dane, the backend developer, asked which database the staging environment uses. Nothing merged, nothing created, nothing sent. That is twenty minutes of decisions instead of a day of supervision. Every one of them is a decision a founder actually wants to make.

A platform is not a workflow builder

People also confuse an AI employee platform with a workflow builder, and that confusion costs teams months. A workflow builder makes you the author of the process. You map the triggers, the branches, and the failure paths in advance. The flow then does exactly what the diagram says. That is both its strength and its limit. Some work never varies. A form comes in and a row goes out. For that work, a workflow builder is the right tool and the cheaper one.

A job is not a fixed process. Find out why signups dropped. Fix this bug. Follow up with that client. Each of those is open-ended, and mapping every branch in advance is exactly the work you were trying to hand off. A platform starts from the role instead: what this employee owns, what it refuses to do, who it reports to. The clawployees page splits the two categories the same way. It starts from a job title rather than a flow, and I think that split is right.

In aldena the difference is visible on screen. There is no flowchart anywhere in the product. You hire roles into a room. When you want structure, you draw the org chart, which is a picture of who reports to whom. Each agent gets one line to its manager, and that single line is the routing. Work travels down manager lines and results come back up. Redraw the chart and the routing changes, with nothing else touched.

The bigger difference shows up over weeks. A mapped workflow does the same thing on day ninety that it did on day one. An employee under review builds up context. Each agent keeps private memory, and each room keeps shared memory that every agent reads. The agent that learned your default branch and your conventions last week starts this week already knowing them. I write more about the management layer in AI workforce platform. The short version is that a workforce needs one place to manage it. A workflow builder was never designed to be that place.

How a three-person team runs this in aldena

The setup I recommend to small teams is very plain. Create one room for one project. The room comes with its own server, its own connected integrations, and its own credentials. Agents hired into it can reach nothing outside it, so one client's work stays apart from the next client's. The mechanics are on the isolated rooms page.

Hire three or four roles, not the whole roster. An analyst, one developer, and a reviewer is a normal starting team. That is enough for a real hand-off chain, and small enough that you can follow everything that happens. Leave the chart flat and talk to each agent directly. Put them under a manager later, once one request should turn into work for several agents at once.

Then give the room one deliverable you actually need. Avoid benchmarks and toy tasks. Pick the feature that has been on the list for a month, or the bug nobody has time to reproduce. Set every tool that writes to ask, so it stops at the approval gate and waits for you. The worst outcome of the whole experiment is then a pull request you close.

The money side is sized for this kind of team. The free plan covers a couple of people, a couple of rooms, and a handful of agents in each. That is enough for the trial I just described. Model usage comes out of one prepaid credit balance, charged at the provider's published list rates. So the cost of running an agent is one number you can watch. The room's server costs a few cents an hour. The current sizes and rates sit on the pricing page. When the balance runs out, work pauses instead of running up a bill. Finding out whether an AI employee platform works for your team costs very little, and far less than adding a person.

Treat it like a probationary hire

The clearest thread I have read on this category is one on r/AI_Agents. The working verdict there on AI employees is that they are like interns: useful, but they need supervision. On day one that is simply true. So I design for supervision instead of pretending it is unnecessary. The platform's job is to make supervision cheap. Every risky action is visible before it happens. Every finished piece of work lands in a tool you already review. Every question goes to you instead of being guessed at.

Autonomy then widens the way it does for any hire. Each "always allow" is one specific permission, granted after you watched the exact call it covers. A few weeks in, the routine work runs without stopping. The gate only stops the work where it should. If you want the step-by-step version of setting up a first team, I wrote it in how to build an AI agent team. You can start smaller than that. One room, three roles, one real deliverable. Then read the pull request when you get to it.