"Digital employee" has become a name you paint onto a chatbot. Give the assistant a headshot, a first name, a Slack handle, and the deck writes itself. It answers questions in a box. When you close the tab, it stops existing.
That is not what the phrase should mean. Think about a real person you hire. They do not stop existing when you leave the room. They have their own laptop. They pick the work back up the next morning without you re-explaining the job. They know how things actually get done here, not because someone wrote it down, but because they have been doing it. A digital employee worth the name is built to mirror that persistence: your working life reflected into a digital space, with a computer of its own and a memory of how you work. And unlike a human hire, it can also act overnight, when you are asleep and they are not.
A digital employee is not one agent answering questions. It is a persistent worker built on three pillars — Employee, Knowledge, Work — and each pillar only works if it is dynamic, not hard-coded.
The Employee
The first pillar is the worker itself. Not a single chat thread: a system with subagents and agent teams, skills, instructions, tools, and workflows. It has its own computer and acts on your behalf. It can sit in a meeting. It can hold a task open across days. That is the employee.
But sales does not look like engineering, and engineering does not look like ops. The tools change. The judgement changes. The shape of a good day changes. So the real question is not "can you spin up an agent?" It is: how do you build something adaptable enough that the same idea of a worker can fit different roles, different systems, and different ways of working, without starting from scratch each time?
That is what the workshop is for. Not the employee running. The place where you assemble it, extend it, and keep those pieces coherent as the work changes. The employee runs. The workshop is how you shape what it can do.
And the part that separates it from an assistant in a chat box is what it remembers, and how.
Memory is where most systems flatten everything into one blob and lose the plot. The way you work inside a CRM is not the way you work in chat. The way you handle an ERP record is not the way you research a competitor. Memory has to be concentrated per tool: a separate, dense understanding of each place you work, kept aligned with what actually happens. A deal moves stage. A thread shifts. A record updates. The employee should know, because those events are the memory, not some summary of them written after the fact.
Memory then combines with integrations and skills. And a skill, done right, is a reproducible set of steps, not a fixed script. Every time you update a deal after a call, or answer a recurring kind of client question, you roughly know how you did it last time. You do not run the identical steps. You tailor them to the case in front of you. The failure mode is the static skill: always do it exactly like this. That is not a skill, it is a stencil, and it breaks the moment the case is slightly different. The Employee pillar has to adapt memory, skills, instructions and integrations to the particular situation. Dynamic, or useless.
Events alone are not enough either. Real work is goal-shaped. Day to day you are balancing projects, each with something you are trying to get over the line this week. Alongside that sits the longer arc of the role: where you want to be in two years, what you are building toward, what you are deliberately not chasing. Without that orientation, every notification looks equally urgent. With it, the employee can tell a noisy ping from something that actually moves the work you care about.
And the work does not only move when you are at the keyboard. Something changes in a tool you already use: a message that needs a decision, a new record in the CRM, a reply on a professional network, a news item that lands on something you own. An assistant in a chat box only sees it when you paste it in. A digital employee has to wake on those changes itself. Arriving is not the same as mattering. And mattering is not the same as "go do it."
The first job after a trigger is triage. Does this loop back into a project or a goal I am holding, or is it noise? If it matters, is it something the employee should handle alone, or something that should escalate to you for a confirm? Digital employee work costs real money and tokens. Running every notification as a full job is how the bill blows up. So the bar is not only relevance. It is worth the spend.
Permission sits next to that. Reading a mail is not the same action as sending one. Drafting a reply is not the same as hitting send. Looking up a CRM record is not the same as updating it. The employee needs a clear sense of what it is allowed to do on its own, what needs a human yes, and what is simply out of bounds. Wiring the trigger is easy. Knowing what to do with it, and whether to do it at all, is the whole job.
Change → triage (matter · cost · allowed) → act alone, ask a human, or skip. Memory and goals decide relevance. Permissions decide how far it can go. Cost decides whether it should run at all.
The last part of this pillar is the one people get wrong on day one. They assume the employee can do everything out of the box. But any tool a person actually uses (a coding agent, a chat harness) evolves. It evolves on two axes at once: context (memory, integrations, skills, instructions) and capabilities. Say you can reach an internal database and the employee cannot. The wrong answer is to file a request with developers or wait on a vendor's roadmap. The workshop should take that request and build the integration itself, so a non-technical person can extend their own employee. That comes with real security and sensitivity concerns, and it should. The direction is still clear: the employee grows, and it does not need a queue of engineers to grow.
Knowledge
The second pillar is how fragmented data becomes something the employee can use. This is the pillar everyone underestimates, because from a distance it looks like a search problem, and it is not.
Start with the shapes. Structured data: spreadsheets, CSVs, the rows inside an ERP or a CRM, on-prem systems that never leave the building. Unstructured data: documents, slide decks, markdown, scanned pages from years back that no one has opened since. And then the sources everyone forgets: social platforms and media. When you research a product feature, you scroll forums, you read professional networks, you read threads. Social is one of the largest parts of how we actually learn things. So why should the employee be blind to it? Add video, audio, images, tables, charts. The employee has to comprehend all of it, not just the tidy rows.
But volume is not the hard part. Relevance is. Suppose you could pull five terabytes in fast. You still have not solved anything, because now the question is what matters. Here is the example everyone recognises. You iterate a report. Version 2, version 3, version 4. Weeks later there are 37 documents in that folder, and exactly one of them ends in _final. That is the one that counts.
Does the employee need the previous 36? Only the final one? Or does it need to know why the first 36 were superseded?
Those are not rhetorical questions. They are the open problems the Knowledge pillar has to face, and the answer is not the same every time. Sometimes the history is the point: the reason v14 died is why v37 exists. Sometimes the history is dead weight. A hard-coded rule ("keep only the final", "keep everything") is wrong in both directions. The filter has to follow the case, not a stencil.
Relevance also has a clock. You can always tell the employee "go check this, go check that." That is useful, and it is not enough. Knowledge should accumulate against the goals from the Employee pillar, not only when you remember to ask. Say your aim is to become strong in computer science, and cybersecurity in particular. Then the employee should be learning that field in the background: papers, articles, shifts in the threat landscape, the boring weekly drip that keeps someone current. Relying on a model cutoff date, or a one-off web search when a question appears, is how you discover too late that the ground moved.
When you later ask a question, or open a project in that area, you want confidence the knowledge is already up to date, not assembled in a panic from whatever the first three links said.
And we are not only talking about the internet. You learn in a car listening to an audiobook or the radio. You learn by scrolling. You learn in conversations that never become a document. Companies have started shipping physical capture devices for exactly that reason: so talk does not vanish the moment the room empties. There is a hard limit to what you can capture while you are stuck at a computer, and there is a harder limit around consent and what should never be recorded. The point stands anyway. Knowledge arrives across the board of a working life. The pillar has to be able to take it in periodically, tied to what you are trying to become, not only when you paste a URL into a chat.
On-demand checks still matter. Background accumulation against goals is what stops every project starting from a cold search.
Work
The third pillar is where the output actually lives: what the employee produces and hands back. If the first two pillars are what the employee is and what it knows, this is the work itself.
Day to day, that is the ordinary stuff of a working life, in four shapes: messages, documents, views, and tools that run. An email or a chat handoff. A report or a board deck. A chart or a live look at the numbers. A small automation that removes a painful Monday task. This pillar is where all of that generated work goes and lives.
Ask for a summary and sometimes the right artefact is a single line in a reply, sometimes a two-page brief, sometimes a chart that lands the point faster than either. Choosing the shape is part of the work, not a setting. A stencil produces the same format every time and leaves you to do the translating. A worker produces the format the situation calls for.
You do not give a board the presentation you would give to the person sitting next to you. Same underlying facts, different argument, different emphasis, different things left unsaid. That judgement is not a slide template. It comes from knowing the audience.
And audience is bigger than "board" versus "desk neighbour." A digital employee has to know who you work with: who is in your network, who sits in your office, who your superior is, who your colleagues are, who owns which project and which piece of information. Some of that is personal to you. Some of it is organisational structure that exists whether this employee is yours or someone else's: reporting lines, ownership, what is shared company knowledge and what is not.
Without that map, even a simple request falls apart. "Craft a message to Susan." Who is Susan? How do you usually speak to her? What can she know, and what stays with you? Same when you are assigning work downward. You own the whole project; they only need a slice. The employee has to know what that person can be told, and what is above their level. What is sensitive? What is PII? What is fine to pass on?
The output only sounds like you, and only stays safe, if it is built out of how you actually work and who you actually work with, not out of a house style someone configured once.
The first version is rarely the last. You send a report. It comes back with three comments and a request to rework the second section. A one-shot generator treats that as a brand new ask and starts again from scratch. A worker treats it as the same piece of work, continued: the draft, the feedback, the rewrite, and why the rewrite happened all stay together. Not lost across a chat thread and a shared drive. The Work pillar holds that history so the next pass builds on the last one.
Audience and sensitivity apply to all four artefact types. Who can see what matters as much for a chat handoff as for a board deck. A draft report sitting with you is one kind of risk. A tool that starts moving data, sending messages, or changing records on its own is another. That second kind needs a tighter yes from you before it goes live. Same idea, smaller scale, for messages: writing the text is not the same as hitting send.
Building those tools is what the workshop from the first pillar is for. If the employee can extend what it can reach and build, it can hand you the automation itself, not a ticket for someone else. Useful, and only with your say-so.
Put simply: the Work pillar does not stamp the same output for every person and every week. It draws on what the employee remembers about how you work, what Knowledge says is relevant, and who the people involved are. Then it shapes the artefact for that case. Fix the format once and forget the context, and you get a stencil. Keep the context in play, and you get work that fits.
The shape is clear. The distance is real.
The industry conversation still snaps back to the frontier model. A new release lands. A conference keynote. A write-up of someone else's architecture. Useful work. It is not the same question as: what does a digital employee actually need to be, in the tools and roles people already have?
Parts of what this post describes are already workable. Tools, workflows, subagents, and skills have moved fast. People are shipping harnesses and rewriting software to be agentic. A lot of it runs today. A lot of it could be better. And a lot of what the three pillars ask for is still out of reach on a normal person's machine, or on software that was never built to be driven this way.
Start with where the worker even lives. Plenty of people want this open: run it yourself, keep the sensitive material closer, see what leaves the machine. Others will be fine on someone else's servers. Either way, the gap is obvious. The models that make the ambitious version feel possible do not fit on an average laptop. Local open-source models that do fit cannot yet carry the full job. So the digital employee described here is partly here, and partly still waiting on compute, on packaging, and on trust about what data moves where.
The Employee pillar has the same split. The workshop idea is the right direction: ask for a capability you do not have, and have the system grow toward it. We are closer on skills, workflows, and subagents than we were even recently. We are not close on the hard integrations. On-prem systems. Software from twenty-five years ago that never expected an agent in the loop. Tools with thousands of functions and no clean API, no MCP, no safe way in. AutoCAD is the blunt example. A mechanical engineer lives in a product with a near-endless surface. Building a digital employee that can sit in that work on their behalf is not a weekend workshop task for a non-technical person. It is years of dedicated engineering, if the product even lets you in. Until more of the world's software is reachable, the Employee pillar stays partial: strong where the tools are open, stuck where they are sealed.
Knowledge has its own ceiling, and we have already named the main one: context. Video, audio, thousand-page documents, conversations that never became files. Embeddings help. Orchestration helps. None of that deletes the limit on how much an employee can hold at once, or how confidently it can stay current across every channel a working life actually uses. The market turns quickly here. The direction is obvious. Getting there still takes a lot of careful work from a lot of people.
Work is the same story at the harness layer. Choosing the artefact, fitting the audience, keeping revision history, knowing when draft is not send: some of that is shippable now. Spanning it cleanly across messages, documents, views, and tools that run, for people who are not already deep in AI tooling, is not done. Most people still are not using this stuff day to day. The pillar only becomes real when the ordinary case works, not only the enthusiastic one.
And yes: employees that talk to each other belongs on this list too. Not as a fourth pillar in the definition, but as a problem that appears once the first three are solid enough that many people have one. Tacit knowledge dying in coffee chats is real. So is the requirement that the default stay private. That connective layer is part of the destination. It is not where the definition starts, and it is not honestly solved yet.
So where does that leave the phrase "digital employee"? Not as a chatbot with a headshot. As a persistent worker on three pillars: Employee, Knowledge, Work — dynamic, goal-shaped, careful about cost and permission, and still unfinished in the places that matter. Enough of it works today to build toward. Enough of it does not that the honest close is this: the shape is the easy part to write down. Making it ordinary is the engineering. Grateful for everyone already pushing on those limits. We are hoping to be among the people who help close the gap.