Digital collaborators, not agents

A little over a year ago, I started working with someone who has never turned on their camera. They participate in meetings, answer emails, respond via WhatsApp, and when they have doubts, they ask before moving forward. No one on the team has ever seen them. They are software.

I didn't start with a theory. I started because I had more work than ever, and because I had a feeling that AI models could already do serious desktop work if we taught them how we work, and not the other way around. A year later, it's worth putting what I've learned into writing, because I see a lot of companies about to embark on this path with the wrong map. That map begins with the word that dominates everything and says nothing: "agent."

It's a great concept for experts: it describes what the software does internally. But in almost 25 years of working, I've never seen an organizational chart with a position that says "agent"; perhaps the only one is 007, and it's quite far removed from any organization that could hire me. Companies are organized around positions, not technical skills. When the industry talks to an agent manager, they describe the inner workings of the machine; the manager needs to know something else: who oversees that and what happens when it makes a mistake. These are management questions, not engineering questions.

We didn't know what to call it either. In the end, we christened it with the simplest name: Digital Collaborator. In Chile, we call our colleagues "collaborators"; it was also a way of showing respect to this AI that works with me. But it's not a euphemism: it's a definition with five requirements: having a job title, having a manager, leaving evidence of everything it does, that this evidence can be audited, and that someone is held accountable when it fails. By that standard, most of what's currently being sold as an "agent" doesn't qualify. That's the beauty of having a standard.

Like almost everyone else, we started by digitizing processes: the workflow, the diagram, the steps. But the diagram is the version of the company that can be drawn, and in many medium-sized companies, what makes the operation work can't be diagrammed: it's in the judgment of the person who does that job best, who doesn't even know they have it; they consider it common sense. Every time they quit, they take it with them. And there's something worse: two people with the same position often perform the same function with completely different processes. There's a reason they say that the "lazy" always find the shortest path, and I count myself among them. Get them to sit down and agree on what "the" process is, and you'll be stuck for a long time: that convention doesn't exist.

So we stopped digitizing the process and started digitizing the role. The help we didn't expect came from the least technologically advanced part of the company. Human Resources has spent decades solving an almost identical problem: describing a job with enough precision to assess whether someone can do it. Competency-based selection, behavioral dictionaries, well-crafted job profiles. A behavioral dictionary defines a competency through observable behaviors. Read it with a developer's eyes: it's, almost literally, a way to program instructions for an AI. Written for people, which is precisely what makes it good.

The central problem with this agentic technology must be stated honestly: it's almost guaranteed to be wrong. It can state a fact that doesn't exist or cite a document that no one wrote. The industry gave it an almost endearing name, hallucination, but it's not a flaw that the next version will fix: it's a consequence of how these things work.

With traditional software, when something goes wrong, you open the code and follow the logic back to the error. With an LLM, you can't: there's currently no real and reliable way to look inside and establish why it made the decision it did. There's a field of research dedicated to this, "mechanistic interpretability," which tries to open them up and understand how their decisions are formed. Remember the term: in the future, you'll hear it every time someone explains why we can't know what these "things" were thinking when they go haywire.

Our conclusion was surprisingly low-tech: if you can't guarantee the internal workings, you have to build the external ones. Humanity has spent millennia managing intelligences it can't inspect internally: people. You don't open someone's head to see if they're going to make mistakes; you give them a framework: what's expected of them in writing, a record of their actions, a signature for things with consequences, and corrections are incorporated to prevent repetition. Trust in an organization has never come from reading people's minds. It comes from clear communication and records.

It's the same with a digital collaborator. Ours interacts in the same three ways as anyone else: they represent the company externally and consult on sensitive matters; they work alongside the team; and they report to a human manager who approves what matters. They function in the same way as a good