What is an employent? (and why we started with marketing)

Telling people you build your own agents isn’t much of a headline anymore. They respond inside a session, run tasks, call tools, and can even make decisions by following a set of rules. So what is an employent, and why does it need its own name? It’s what’s still rare: an agent that holds a role on the team the way an employee does, instead of existing only for the length of one conversation. In most cases, an agent’s existence ends when the interaction ends — no role inside the organization, no ongoing responsibility for its work, nobody waiting on results from it next week.

An employee has all of that. An identity, a role, a set of responsibilities, and a context that goes beyond any single conversation. Their work is part of an ongoing process, with shared goals, results that get tracked, and a supervision relationship that makes it possible to review decisions, adjust course, and learn from what happens.

Between an agent that executes tasks and an employee who occupies a role, there seems to be a space that doesn’t have a clear name yet. This article answers that question in full — what an employent is, the word we’re proposing for that space — along with the reasons that led us to build the first one for our marketing department.

What is an employent? The difference between a tool, an assistant, and a teammate

Before answering what an employent is exactly, it’s worth knowing the line the industry itself already draws between an automated workflow and an autonomous agent:

• A tool is something you operate: it has a text box and no idea what your job is.
• An assistant helps inside a session, but it has no role, no presence outside that session, and nobody asking it for results next week.

Neither of them gets to be what an employee is: someone with a role, a scope of authority, and a presence on the team’s platforms, plus an identity of their own and someone who reviews their work.

An employent takes exactly those four properties of an employee and turns them into design commitments: they don’t describe what one particular employent does, but what any of them has to satisfy by definition. In our case, that design lives inside Slack for now — the tool the team uses to communicate. That’s where you mention it, and where it decides whether to answer or not.

The four are the same question asked in four different ways: how much control do we keep over what it does, over how it reasons, over the software it runs, and over what it costs?

Identity, not a login

An employent needs a name of its own, and the team has to be able to address it like any other colleague. That’s why each one has its own Slack user: none of them shares an account with another role, in the same way a person doesn’t share their login with a coworker.

Permissions closed by default

Because it lives in Slack, it needs a list of channels where it’s allowed to answer — and if that list is empty, it shouldn’t answer in any channel at all. Being added to a channel is not the same as being on duty in it. And since every mention is also a (potentially paid) call to the model, this control has to do double duty: deciding where the employent acts and putting a brake on spend.

No memory between one mention and the next

The way we see it, an employent shouldn’t own a database of its own. Every mention has to be a short, isolated run that rebuilds context from what a person could also read at that moment (the Slack thread, a Notion draft): it decides, it acts, it finishes. Nothing that happened in one mention should leave a trace for the next one.

It never publishes

The final publish always has to be done by a person (for now), never by the employent. Not as a matter of permissions, and not as a rule that could be broken, but because the system has no capability whatsoever to publish to the outside world. That’s why we measure the project’s success differently: it’s validated when the team chooses to use it every week because it genuinely adds value.

Why the first employent is in marketing and not in engineering

We use engineering agents constantly, but we don’t consider any of them an employent. They build things for us every day and they’re powerful agents — but they’re not employents (yet).

Marketing was already automating part of its content creation workflow before this project: we had ground already won to take the next step.

On top of that, it met a set of requirements that made this department the best playing field for deploying our first employent:

1. The knowledge was already written down. Brand voice and per-channel skills were already a versioned source of truth, reviewed by humans.
2. There was an expert on hand to review it in depth. The whole quality strategy depends on there being human judgment at the end: the first generated drafts went through real checks, with concrete findings to fix on every iteration.
3. There was a concrete use case identified. Of the many use cases you could fully automate in marketing, we spotted that turning our internal video sessions into blog articles was the best candidate: Zoom recording → transcript → draft in our voice → Notion → an expert corrects it there → tone and style iterations → technical validation → English translation → image generation. All of it set up so a person can then publish on the website.

Why an employent is not just a more autonomous agent

While the industry trend is to chase agents that are more and more autonomous, able to chain more steps with nobody supervising them, we’ve started a different race. We care more about what place AI occupies inside a real team than about how many steps it can chain on its own.

Because it isn’t only about what an agent is capable of doing: generating a post, reviewing a pull request, running a test suite, or coordinating several tools. As long as it stays a capability someone switches on when they need it, it will keep working as an advanced tool, however autonomous it is.

The employent concept introduces another possibility: that work can be organized around a role you can turn to, instead of around a conversation with a model. That also changes how you build it. It’s no longer enough to ask what tasks it can execute — you have to ask what part of the work it can take on, where it’s allowed to act, what limits it has, and how it fits with the people already doing that work.

That doesn’t mean handing responsibility over to the AI. An employent can hold a role inside the team, but the judgment and the responsibility for the outcome stay human. In fact, that separation is part of the design: the more integrated the system is in real work, the more it matters to know which decisions still belong to people.

That’s the goal of the roadmap we’ve started in marketing: to validate that an AI capability can become something the team folds into how it works in a stable way, without turning it into a black box or confusing operational autonomy with autonomy of judgment.

The first employent is already working. Now we get to find out whether this model holds up when we change the role, the context, and the kind of work.

An employent can hold a role inside the team, but the judgment and the responsibility for the outcome stay human

FELIPE POLO
CEO Orbitant

How is it different from a Slack bot?

Hermes, Grok Bot and the like live where our first employent lives: in Slack. From the outside they look very similar.

On the inside they split apart along the four properties above. A bot is something you invoke: it inherits the permissions of whoever writes to it, it answers in any channel it’s been added to, and nobody asks it for results next week. By our definition, that’s a well-integrated assistant.

What changes is the control: over its actions, over its reasoning, over the software it runs, and over what it costs. How we implement each of the four is the subject of the next article.