Why I’m Building a Digital Employee System

2026-06-05T10:00:00+08:00

I am building a digital employee system.

Let me set the boundary first: this is not a mature product, and it is not a complete public case study yet. The repository, demo, and implementation details are still being organized. What I can share now is the direction, the problem context, the hypothesis I am testing, and the build notes I plan to publish next.

I am writing this down because I increasingly believe the important question for AI agents is not whether they can produce an impressive demo. The question is whether they can complete a piece of work inside a real workflow in a way that is reliable, recoverable, and supervised.

There Is a Gap Between Demos and Work

Many agent demos look impressive. An agent can read files, call tools, write code, generate plans, and simulate a full task chain.

But a working demo is not the same as a reliable system.

Once agents enter a real workflow, the questions become much more concrete:

Are the task boundaries clear?
How does context move between agents?
When a tool call fails, does the system know where it failed?
Which parts of the state are still trustworthy?
Should the next step be automatic recovery or human review?
How is the result verified?

These questions are less flashy than model capability, but they decide whether an agent can move from a one-off demo to a repeatable system.

What I Mean by Digital Employee

By digital employee, I do not mean “a chatbot that sounds more capable.”

I mean a working system:

It receives a clear work objective.
It breaks the work into executable steps.
It calls tools to complete parts of the task.
It preserves state and recovers from failures.
It asks for human judgment when uncertainty matters.
It leaves a trace that can be reviewed and improved.

In other words, a digital employee is not a single model. It is a system made of models, tools, state, protocols, evaluation, and human checkpoints.

The Hard Part Is Not Chat

Chat ability matters, but it is not the part I care about most.

The engineering questions matter more:

Coordination protocols: how do agents divide work? Who plans, who executes, and who reviews?
Tool reliability: what happens when a tool call fails? When should the system retry, and when should it stop?
State recovery: if execution fails halfway through, which intermediate state can still be trusted?
Human review: which steps must ask for human confirmation, and which can safely run automatically?
Result verification: how does the system know it completed the work, instead of merely appearing to complete it?

None of these problems can be solved completely by a single prompt. They need system design, and they need many small experiments.

Current State

This project is currently active.

I am organizing three directions:

task boundaries and context handoff between agents
recovery behavior after failed tool use
human checkpoints and system boundaries

I have not packaged this as a product, and I have not published a specific repository yet. That boundary matters. If I cannot explain what the system can and cannot do, I should not present it as a finished result.

What I Want to Validate Next

The next step is to clarify the system before showing more interface.

I want to document:

what the current prototype can actually do
which steps still require human review
how the system responds when tool calls fail
which implementation details can be public
whether a more specific repository or small demo can be opened

These notes should become part of the build log, not remain private thoughts.

Why This Is Worth Doing Long Term

I believe AI agents will change work not because of one impressive demo, but because many reliability details slowly become stronger:

clearer boundaries
recoverable failures
better human checkpoints
traceable work
systems that can be maintained over time

That is also why I am building this site. It is not meant to present a perfect image. It is meant to turn judgment, experiments, and writing into a long-term research system.

The digital employee system is only one experiment, but it will be one of my most important build objects for the next phase.

Building a Modern Frontend Project with Vite

2026-05-20T10:00:00+08:00

This note records how I set up a clean, fast, maintainable frontend experiment with Vite. It is a practical setup note, not a complete framework tutorial.

“Tools should serve thought, not the other way around.”

Why Vite

Vite leans on the browser’s native ES Modules support, so dev mode skips bundling entirely — and startup feels instant. Compared to the traditional Webpack flow, the wins are:

Cold start drops from seconds to milliseconds
HMR is essentially instant; the bigger your project, the more obvious the gap
TypeScript, JSX, and CSS preprocessors work out of the box
Production builds use Rollup, with smaller output than Webpack

The terminal output below shows what npm run dev looks like — note the 187ms startup:

Vite dev server · cold start in 187ms

Getting started

A single command bootstraps a new project:

npm create vite@latest my-app -- --template vue-ts
cd my-app
npm install
npm run dev

Open http://localhost:5173 and you’ll see the default page.

I am not embedding a video demo here yet. If I record a real project walkthrough, I will link it from Elsewhere or add it to the article later.

Common configuration

Here’s the vite.config.ts I keep around:

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import { fileURLToPath, URL } from 'node:url'

export default defineConfig({
  plugins: [vue()],
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  },
  server: {
    port: 3000,
    open: true
  }
})

Closing

Tools change. The shape of the problem doesn’t. I hope this saves you a few of the potholes I’ve stepped in. Drop me an email if you’ve found a sharper approach — I’d love to hear it.

Written in May 2026. Corrections welcome.

Benjamin Taoson · 赖建铭 · English