DEV Community: coffee

When xAgent Connects to Databases, AI Can Work Directly with Business Data

coffee — Thu, 20 Aug 2026 01:57:20 +0000

Databases were one of the missing pieces in xAgent.

Database Connector is the governed channel between xAgent and MySQL or PostgreSQL. It gives an Agent db_list, db_getinfo, and db_execute_sql to discover connected databases, inspect resource information, and execute SQL. Database addresses and credentials remain in the Connector Server, while the database account's native permissions still decide whether a statement can run.

xAgent could process files, call tools, operate browsers, and keep tasks running on a server. But when the real business data still lived in MySQL or PostgreSQL, there was another layer between the Agent and the work. Someone had to export a file or build an API first, and every change in the source data could make that handoff stale.

With Database Connector, an xAgent task can find an available database, inspect its structure and data, execute SQL allowed by the current account, and carry the result into the next stage of the task. To me, this is more than one more tool. It is the point where xAgent can work directly with business data.

Long-Running Tasks Can Keep Using the Database

The usual way to give an Agent a data task lasting hours or days was to export a CSV, let it process the file, and import the result later. Large exports quickly became a bottleneck. If the source changed while the task was running, the export was already out of date.

A database can now remain a stable external resource throughout a long-running task. The Agent can query one batch, analyze it, and continue with the next. When its account has write permission, it can also store intermediate results or processing state in a business or analytics database and continue from that data later.

This does not turn the database into xAgent's own Memory. It gives the Agent real data input and output while it works.

The Task in the Screenshot: A PostgreSQL Patrol Every 15 Minutes

The task below starts from a timer. Every 15 minutes, xAgent checks PostgreSQL for slow SQL, active connections, long-running transactions, cache hit ratio, and table bloat. One patrol executes several SQL statements and compares the current values with explicit thresholds.

A timer starts the patrol, and xAgent makes several db_execute_sql calls in the same task round.

No one has to remain beside a chat window. A healthy round can stay quiet. When a metric crosses its threshold, the Agent can report the actual value, likely causes, and recommended action. Connect WeChat, Telegram, or Feishu, and that alert can go directly to the person responsible.

The Important Part Is Not Merely "Running SQL"

Work Across Databases

Database Connector does not restrict one user to one database. An administrator can define multiple MySQL and PostgreSQL resources, and a user can connect to several of them. The Agent first discovers the available database_id values and then selects the right data source as the task develops.

It can retrieve business facts from an orders database, compare them with supply data in an inventory database, and then inspect historical trends in an analytics database. The Agent orchestrates that cross-database logic inside the task. The Connector does not pretend those databases share one transaction.

Run Multiple Tasks Concurrently

xAgent is not a single-script process that can do only one job at a time. Separate Sessions and long-running tasks can work concurrently, and separate users can connect to the same resource catalog with their own database accounts. The resource model is not fixed to one database or a small predefined set.

Operating hundreds or thousands of databases still requires capacity planning for Connector instances, connection pools, task concurrency, target database limits, and model cost. Those are real engineering boundaries and should not be hidden behind an untested capacity claim. What has changed is that moving from one database to a database fleet is no longer blocked by the protocol or product model.

Analyze and Optimize Data

With direct access to current data, an Agent can combine analysis and business processing in one task. It can investigate slow SQL, lock waits, long transactions, index usage, and table bloat. It can also reconcile records across databases, find anomalous samples, generate reports, or write processed results to a designated table.

The useful part is not that a model can produce a SQL statement. It is that the Agent can query data, verify the result, adjust the next step, and continue until it finishes a task with business meaning.

Database + Trigger + IM Connector Completes the Loop

Database Connector alone answers how an Agent reaches data. Combined with xAgent timers, external triggers, and IM Connectors, it becomes a business loop that can keep running:

Timer / external event
          ↓
        xAgent
          ↓
 Database Connector
          ↓
 Query, analyze, decide, act
          ↓
 WeChat / Telegram / Feishu

That loop maps to concrete work:

Database monitoring and alerts: check slow queries, connections, locks, and storage on schedule, then notify only when something is wrong.
Database optimization analysis: use statistics views and query behavior to suggest index, SQL, or cleanup changes.
Data analysis and mining: examine relationships across business databases and produce metrics, anomalous samples, and reports.
Scheduled data processing: run reconciliation, quality checks, aggregation, backfills, and result writes on time.
Business event handling: receive an external event, query current data, decide the next step, finish the work, and notify the relevant people.

The Model Does Not Own the Permission Boundary

Database Connector does not place database addresses or passwords in conversations or tool arguments. Administrators define database resources, users connect with their own database accounts, and credentials remain in the Connector Server.

The database account's native permissions decide whether a SQL statement can run. Monitoring and analysis should start with a read-only account. Writes, DDL, and other risky operations should use separately scoped permissions and approval rules.

The Connector also bounds each query by timeout, maximum returned rows, and result size. These limits do not replace database permissions, but they keep one tool call from consuming unbounded time or context.

What This Actually Completes

Database Connector is not a cloud database administration console, and it does not automatically turn AI into a DBA. It completes the basic path for remote database use: discover a resource, authenticate, execute SQL, receive the real result or error, and return to the long-running task.

Before this, xAgent mostly automated work around data. Now it can enter the data layer. The interesting change is not that the Agent gained another kind of call. It is that the database has become a business resource that a long-running task can keep using. A timer starts the work, Database Connector reads and processes data, and an IM Connector delivers exceptions and results to people. That is a data workflow capable of continuing on its own.

Database Connector currently supports MySQL and PostgreSQL. See Database Connector Setup for configuration and xAgent Connector Management for the broader Connector boundary.

Why I Built xAgent

coffee — Tue, 18 Aug 2026 03:35:34 +0000

I started building xAgent in April 2025.

The original idea was straightforward: build a task-oriented Agent that could run work on its own and turn AI into real automation. Looking back, that sentence sounds simple. Most of what I have done over the past year has been filling in everything hidden inside the words “run work on its own.”

The first version used a single Agent. I quickly ran into a problem: once the prompt focused its attention on one kind of work, the Agent could do that work well but handle other tasks terribly. Fix one side and it would forget the other. Ask it to pay attention to everything and it would end up paying proper attention to nothing.

That led me to multiple Agents, each responsible for a different part of the work and able to collaborate with the others. The idea worked, but as soon as they started running together, the next problem became obvious: tokens were too expensive.

I bought a modified RTX 4090 with 48 GB of VRAM and started running open models locally. That took some pressure off the token bill, but exposed another problem: small open models were not smart enough. This was still the Qwen 3.0 era. The gap between local models and the best hosted models was obvious, especially on long tasks. They skipped steps, wandered away from the goal, and ignored instructions in all sorts of ways.

I did not solve this by buying more tokens from top-tier models. It was not because those models were bad. The most practical reason was that I simply did not have the money. Once multiple Agents run continuously, the allowance included with a subscription disappears quickly. Spending more could solve the problem, but I could not afford to keep doing that, and it did not look sustainable for most individuals or small teams either.

Not having the money forced me to think seriously about a question that has shaped xAgent ever since: can a small team with a limited budget use Agents properly without constantly paying for the best models, keeping costs under control while still getting good work done? The model may be less capable, but the system has to keep the task moving. It cannot let the work fall apart halfway through, or allow one wrong step to turn every later step into another mistake.

I spent the next few months testing over and over again: different tasks, different models, different ways of organizing context. Something failed, I changed it, and then I tried again. By August 2025, I had a first working version.

Around that time, my wife had also started using Agents. I realized that if more than one person at home needed this, I might as well make it multi-user and run it on a server. That decision ended up shaping xAgent in a major way. Many things that now look like product positioning came from a very ordinary need: both of us wanted to use it, and I did not want to install and maintain a separate copy on every computer.

Over time, I also realized that my basic understanding of an Agent may be different from that of many other people.

Most people still see an Agent as an assistant. You call it over while you are working, ask it to find information, revise a document, or write some code. When you stop, its work usually stops too. I have always preferred to think of an Agent as a colleague, or as someone reporting to me.

That does not mean it should replace human decisions, and it does not mean I treat it as a person. I mean the working relationship. I give it a goal. It moves the work forward by itself, comes back when it hits a problem, waits for my confirmation when necessary, and returns with the result. I do not want to sit beside it and explain every click and every next step.

Because I see Agents this way, I care about different things. Can a task continue after an interruption? Can the system pull the Agent back when it makes a mistake? Which actions must come back to a person? xAgent still looks like a chat interface, but the task may only be starting when the user finishes that first message. It may need to research, process files, use tools, or wait for an external message before continuing. A timer or another system may start the task instead. None of this needs to stay tied to the user's computer.

Desktop Agents have their advantages. They are close to the user, can operate the local computer conveniently, and work well as assistance for whatever is in front of you. They can also automate work. But when you expect them to run for a long time, many problems that have nothing to do with AI begin to appear. Does the computer stay on overnight? Will it go to sleep? Is there enough disk space? Is it powerful enough? How do you restore it after a failure? How is the work backed up?

That is why I see desktop and server-side Agents as more than the same product installed in two places. They come from different ideas. A desktop Agent follows one person and helps with the work at hand. A server-side Agent has to keep tasks running, serve several people, and give someone a way to maintain it when things go wrong. This was also when I started thinking about turning xAgent into a commercial product.

I added many adaptations and hard-coded guardrails after that. Some of them are not elegant, but they genuinely help small models. It was not until March 2026 that I felt xAgent was barely ready for other people to use. That became the first public version, 0.0.4.beta.

After releasing it, I spoke with quite a few friends and potential users. They often asked, “How is this different from Codex or OpenClaw? What is your advantage?”

At first, I would talk about security, auditability, multi-user support, and easier team maintenance. Those really are xAgent's advantages, but after enough conversations I realized that most users do not care very much, at least not yet. Their first question is whether it works well and whether it can get the job in front of them done. As long as the bill stays small, the maintenance cost behind the product and the cost of the model rarely decide which product they choose.

Many people currently use AI for a few documents, some research, or occasional information gathering. They do not consume much in a day, and most still pay for it personally. If a company only gives employees a modest allowance for office work, the cost may remain manageable.

But imagine a company where everyone uses AI for more than half of every workday. The bill would look very different. The deeper AI enters daily work, the less this remains a technical department's problem. Every company will eventually have to do the math.

There is another group of companies that must use local compute for compliance, privacy, or data-security reasons. The problem is even clearer there.

Most Agent products are developed and demonstrated with the best available models. A sufficiently capable model can cover up many weaknesses in the surrounding system. Hallucinations, once the most obvious problem, are much less common with today's top models. They are still common with small models, along with failures in instruction following, long-task continuity, and tool use.

I have seen companies buy hardware early only to leave it sitting idle. The demo they watched used a top model, so of course it looked good. In real deployment, cost or compliance forced them to switch to a local model, and the experience changed completely. It could still answer simple questions, but long tasks, information gathering, research, file processing, everyday assistance, and internal-system analysis were out of reach. The machines were there, the Agent was installed, and nobody actually used it for work.

I am not claiming that xAgent has solved all of this. That would not be true. I use Codex while developing xAgent, but most task testing has been done with 27B models from Qwen 3.0 through Qwen 3.6, along with some older versions and variants. Long tasks generally finish. The results can be off, but in actual use I do not think the gap from the leading models is so large that the system becomes unusable. It has reached a point where I can use it for real work.

Once the workflow became more stable, I went back to cutting costs.

I started with prefix caching and kept trimming the prompt. Stable parts of a process became hard orchestration. When the model drifted, the system needed a way to bring it back. Memory could not be a pile of everything the model had ever seen; it needed to be distilled, merged, and brought in only when useful. None of these changes looked dramatic on its own. The result improved one small step at a time.

By 0.0.10.beta, the base prompt had fallen from about 20K tokens to roughly 5K, while task stability and accuracy were better than before. This is difficult to measure cleanly, and the models themselves have improved at the same time. Smarter models naturally produce better results, so the improvement cannot all be credited to the system. Still, put the same model into two different Agent systems and there can be a very visible difference in whether it finishes a long task.

A multi-user server platform also has to solve the problem of connecting external systems.

On a desktop, each person can bring a personal token and configure an MCP server. xAgent cannot simply copy that model. It runs on a server and serves multiple users. Where should authorization live? What is the model allowed to see? How does an incoming message reach the right person? Those questions led me to build the Connector system, which remains one of the parts of xAgent I am happiest with.

Authorization for the target system is managed on the server. The model uses the permitted capability without ever needing the real credentials. A Connector also does more than expose a few tools. It can receive information proactively. If someone sends a message through WeChat, for example, the Connector can deliver it to a dedicated Agent under that user's account. The user does not need to open xAgent and paste the message into a chat window first.

Some people say this is basic functionality on the desktop. They are not wrong. But once many connected systems can all send information back, the problem is no longer just whether the message arrives. Are messages queued or handled concurrently? What happens when the computer is off? Are messages processed while the desktop client is closed? When it starts again, did anything get lost?

A large part of the Connector work is about answering those questions. I want the Agent to keep running without the user being online at that moment, but I do not want it operating without human management. A person should not need to watch every step, but should know what it is doing and retain control over important actions.

Continuing down this path eventually leads to AI workflow products. Most workflow systems fix the process in advance. That makes execution predictable, but it also creates a development cycle. The person building the workflow and the person using it are often different people. By the time the workflow goes live, the need may already have changed. Every later process change brings another round of development.

xAgent still starts from a Skill. A Skill describes how a kind of work should be done, and the Agent makes a plan for the task in front of it. Parts that are stable can be hard-orchestrated, but the whole task does not have to be drawn as a flowchart that can never change. I want working methods to accumulate without forcing every changed task to start over from scratch.

At 0.0.10.beta, xAgent feels relatively complete and stable to me. I use it with a 27B model every day. It sends industry-news summaries to me through WeChat, conducts industry research, gathers information from the web, and writes reports. These are no longer tasks prepared for a demo. They are things I genuinely use every day.

The next missing piece is the knowledge base, which I see as xAgent's last major weakness. It is roughly 30 percent complete. The overall architecture and the logic for chunking, indexing, and graph representation are already worked out. What remains is mainly implementation and testing, which should move quickly.

Once the knowledge base is finished, the core architecture of xAgent will be largely settled. I do not plan to keep making large changes. From there, the focus shifts to giving it more “hands and feet”: connecting to servers for automated operations, connecting to phones to operate apps, helping run e-commerce, media, investing, and quantitative workflows, and training models. I see model training as another form of automation too.

While building all of this, I often wonder what Agents will eventually become.

I do not think they can replace human decisions. People decide what is worth doing, choose a direction, and make the final call. Agents fill gaps in our knowledge and carry out much of the concrete work. That is roughly what symbiosis means to me.

The current moment feels a little like early European industrialization, when horse-drawn carriages and steam engines still ran side by side. Many people worry that Agents will replace human work. I think the first thing they will take away is repetitive labor. People can use the time they get back to plan, or to try ideas they could not afford to try before. Something that once took months to validate may now take days. In some cases, the time drops by a factor of twenty or fifty. People still make the decisions, but making them becomes much less expensive.

I have not completely worked out how this lands in practice. One possibility runs against the common expectation: the more capable Agents become, the less people may need to collaborate with one another. One person with several Agents may take over work that used to be spread across several people and several roles. Teams become smaller, each person owns more, and there are fewer reasons for people to pass work back and forth.

Office assistance may reach that point quickly. If an Agent can handle 90 percent of a role, will a company still keep ten people on a team that used to need ten? From the company's point of view, perhaps one or two will be enough. That is not good news for employees, but I think it will be difficult to avoid. People who understand several fields, can make decisions, and know how to lead Agents through work may become unusually valuable.

Business software may follow a similar path. The people building it will not always be programmers. Employees can ask an Agent to create the tools they need because they know better than anyone what their daily work is missing. Today's huge demand for coding may partly mean that software has not developed fast enough to cover countless specific business needs. Once enough of those gaps have been filled, demand for the same kind of system will naturally fall. Building a system may eventually feel like making a spreadsheet today, hardly something worth announcing.

All of that is still mostly about saving money and improving efficiency. I am more interested in whether Agents can create entirely new businesses.

How far Agents go may depend largely on how many new ideas people can come up with. Models will keep getting smarter, but they will not tell us which business is worth building or which problem is worth solving. Work that used to cost too much, serve too small a market, or make no economic sense may now be worth calculating again. Agents can turn an idea into something real more quickly and make experimentation cheaper, but the original idea still has to come from a person.

The picture I can currently imagine is one with smaller companies and far more AI. One person manages a group of Agents. Those Agents create more Agents as the task requires, and the work continues around the clock. People do not participate in every step, but they still decide what the Agents should do, why they should do it, and when they should stop.

xAgent is still a long way from that picture. But when I design it, I really do think of the Agent as a colleague or a direct report, not just an assistant waiting to be called. I want to hand it a piece of work, go do something else, come back later, and see whether the work actually got done.

I am an engineer. This is about as good as my writing gets, so please bear with me.

DeepSeek Harness vs. xAgent: Choosing an Agent Harness Architecture

coffee — Sun, 16 Aug 2026 18:48:15 +0000

DeepSeek Harness treats the Agent runtime as a composable plugin tree. xAgent starts with a different question: when a task has been running for hours, called Tools, waited for approval, and survived a service restart, who owns each piece of state?

That question sends the two architectures in different directions.

Both sit above the model API and handle Sessions, context, Tools, and execution. Both qualify as full Agent Harnesses. DeepSeek concentrates on making the runtime replaceable and recomposable. xAgent concentrates on keeping long-running work coherent. A feature checklist tends to hide that distinction rather than explain it.

The Revisions Compared Here

The xAgent baseline is 82f3a1f6, dated August 16, 2026. The DeepSeek baseline is 47f94385, committed August 13, 2026.

At that revision, the DeepSeek README still describes the project as a developer preview and warns about compatibility-breaking changes. I am comparing published code and documentation, not predicting future stability. There is no performance ranking here either; tokens, latency, and task success are meaningless without a shared workload, model, Tool set, sandbox, and recovery scenario.

xAgent has no package literally called harness. Brain, SessionEngine, AgentService, ToolService, ProcessSandbox, and multi-Session collaboration collectively fill that role. xAgent is neither a DeepSeek fork nor a product shell built on top of it.

Start with Ownership, Not Tools

From a distance, both systems have an Agent Loop, Tools, Sessions, compaction, Subagents, and sandboxes. The difference appears one layer below.

	DeepSeek Harness	xAgent
Runtime organizing principle	Cordis plugin tree	Stable owners such as Brain, SessionEngine, and AgentService
Primary Session record	Append-only `SessionEvent` log	Chat, SessionMeta, recovery snapshots, SessionEvent, and Memory divided by owner
How capabilities enter	Profiles, bundles, hooks, waterfalls, guards, and providers	Owner business actions plus per-Session Skill and Tool assembly
What recovery protects first	A valid, replayable transcript	Usable task, approval, compaction, and guidance state

DeepSeek is composition-first: split the runtime into parts that can be recombined. xAgent is fact ownership-first: decide who creates, changes, and restores each kind of state.

Those labels sound abstract, so consider a task that fails at an inconvenient moment.

A Task Restarts While Waiting for Approval

Imagine a customer-support report. The Agent has read the tickets, generated a CSV, and is about to call an external Tool to send the report. The call needs approval, so execution pauses. Context has already been compacted once. Then the service restarts.

DeepSeek is particularly good at answering, “What exactly did the model see before the crash?” Its architecture documentation captures the rule in one line: Model-visible means logged. User input, streamed output, Tool calls and results, request headers, and the effective prompt, tools, and model config can be reconstructed from the event log. That is a clean evidence chain for debugging, forking, and replay.

When a process exits mid-turn, DeepSeek keeps the flushed events and appends synthetic unknown / interrupted closers for open Tools, Steps, and Turns. The transcript becomes valid again. Its persistence documentation is explicit about the boundary: the current implementation does not resume a partial turn.

xAgent asks a different recovery question: “Can the task continue?” Approval is represented by a durable RuntimeAuditUnit. Guidance, pending compaction, checkpoints, and active-turn compaction can all enter recovery material. After a restart, xAgent restores business state that lets the Session move forward, not only a valid model transcript.

The tradeoff is equally concrete. xAgent can tell you who owns the current state, but it does not naturally retain one exact record of the prompt, Tool schema, model config, and owner versions seen by every past model call. DeepSeek has the stronger replay story. xAgent has the stronger long-task continuation story.

DeepSeek Feels Like a Runtime Kernel

Almost every DeepSeek capability hangs from the Cordis plugin tree. Effects can be reversed, a local scope can shadow a global capability, and Profile patches alter the final composition. Model adapters, prompts, Sessions, Tools, sandboxes, and Subagents all expose replacement points.

The value is not merely “more plugins.” A developer can replace a whole slice of runtime behavior without rewriting the Agent Loop. The Tool pipeline, for example, accepts guards, wrappers, and finalizers around execution. Tools may be parallel or exclusive, and concurrent results still commit in the model's original order.

Subagents and sandboxes follow the same pattern. Subagent providers can connect in-process implementations, forks, ACP, Codex, Claude Code, and other backends. Filesystem, subprocess, and sandbox providers can replace the Agent's execution world. This is compelling for teams building an Agent runtime laboratory or changing infrastructure components frequently.

xAgent Feels Like a Long-Running Work System

xAgent does not turn every responsibility into a plugin. Brain schedules work and updates task state. SessionEngine coordinates Session facts. AgentService runs the model and Tool loop. ToolService governs calls. The boundaries are less fluid than DeepSeek's, but a business state usually has an identifiable owner.

You can see that priority before the first business-model call. A sub-Session persists the original input, makes one stateless semantic call to classify the task relationship, and produces three groups of recall terms for Skills, Tools, and Memory. Brain applies a five-value enum. Orchestrator recalls and adds capabilities only when the task is first established or changes phase within the Session.

Persist original input
  -> task_relation + three recall-term groups
  -> Brain updates task state
  -> [initialize / reconcile] Orchestrator recalls capabilities
  -> AddSelectedCapabilities
  -> AgentService enters the model / Tool loop

There is no score threshold or second task-extraction call. Orchestrator does not rewrite the Goal, swap the model, or silently unload existing capabilities. When MainSession hands work to a sub-Session, it sends the original request and resource references. The Session doing the work understands the task and prepares its own capabilities.

Once inside the Tool loop, xAgent currently executes Tool Calls in order. ToolService is designed less as an open-ended extension surface and more as a governance chain for paths, enabled state, readiness, schemas, approval, secrets, execution leases, and result normalization. Serial execution is a conservative but sensible default when Tools can modify files, start processes, or touch external systems.

How I Would Choose

If my team keeps asking, “Can we swap this model adapter?”, “Where can we add another Tool guard?”, or “Can we replay the exact model request?”, I would study DeepSeek Harness first. It behaves like an Agent runtime kernel, and composition is its strongest idea.

If the questions are, “Does the task keep running after the user closes the page?”, “Can an approval wait overnight?”, or “Will the Goal, files, and compaction state survive a restart?”, xAgent is closer to the problem. It treats the Agent as a durable business Session rather than a complete model loop.

Most serious systems eventually want pieces of both. The important decision is where primary facts live. Evidence may have many projections; a fact should still have one owner.

What xAgent Should Borrow

I would not turn xAgent into an everything-is-a-plugin system. Brain, SessionEngine, AgentService, and ToolService already form a useful responsibility spine. Making all of them plugins would blur the ownership xAgent has worked to establish.

Request evidence is the more valuable lesson. xAgent could record the effective prompt, Tool schema, model config, and owner fact versions for each call. Those records would make incidents reproducible while remaining projections of owner facts, not a second data source that can mutate the Session.

Tool concurrency is also worth keeping as a conditional optimization. If real workloads show that serial calls are a bottleneck, xAgent can distinguish read-only Tools that may overlap from side-effecting Tools that require exclusivity, then commit results in model order. Adding concurrency merely to look more advanced would buy complexity before it buys performance.

SessionEngine's current dependency pressure has a more ordinary remedy: give each owner better business operations and remove passthroughs. A new plugin core would move the problem rather than solve it.

The Shortest Honest Summary

DeepSeek Harness is better at making the runtime replaceable. xAgent is better at keeping the task alive.

One asks how capabilities should compose. The other asks who owns the facts. Knowing which problem you are solving matters more than comparing the length of two feature lists.

For the implementation details, read the task-alignment deep dive and the execution-loop deep dive.

Originally published on the xAgent documentation site.

Route Sensitive AI Agent Work to an Internal LLM by Agent and Session

coffee — Thu, 06 Aug 2026 05:38:14 +0000

An organization does not need to choose between running every task on an internal model and sending every task to a third-party API. xAgent can create an Agent for sensitive work that defaults to an internal model, then let its Sessions use the matching model configuration: general work can use an external model, while restricted work starts with a model configuration that points to an internal service. The model configuration selects the final Provider, so the two workloads use separate model paths.

This is a specific way to configure an Agent around a data boundary. It complements the general Agent Management workflow; it is not, by itself, an absolute claim that every byte of data stays inside the company. This article explains how to establish the boundary, verify it, and understand what else must be controlled.

Do Not Put Every Task on One Model Path

Most teams have two kinds of work:

Everyday writing, public research, and general coding assistance can benefit from the scale and capabilities of third-party LLM APIs.
Contracts, customer material, operating data, and unreleased plans may need model requests to reach only a model service controlled by the company.

With one default model, people must remember what may be sent to an external Provider. That is error-prone and makes it difficult to give different jobs the right capability set.

A more maintainable pattern is to prepare separate model configurations and Agent entry points for separate task boundaries:

Task entry point	Selected model configuration	Final Provider path	Appropriate material
General research Agent	`general-external`	Third-party LLM API	Public information and routine non-sensitive work
Confidential-material Agent	`confidential-internal`	Self-hosted model or internal model gateway	Restricted business material
One-off sensitive Session	`confidential-internal`	Self-hosted model or internal model gateway	A single confidential analysis

The names are only examples. What matters is that each model configuration maps to an explicit Provider type, Base URL, credential, real model name, and capability declaration.

How Three Configuration Layers Create a Provider Route

Agents and Sessions in xAgent do not store a raw Provider URL or API key. They select a model configuration name, and the server resolves that name to the matching Provider client. Credentials and network addresses therefore remain in administrator-managed configuration instead of appearing in Agent prompts or conversation content.

Layer	What it stores	Responsibility
Model configuration	Model name, Provider type, Base URL, key, capabilities, and default policy	Defines where model requests go and what the model can do
Agent definition	Role, Skills, Tools, and a default model configuration	Provides a reusable capability and routing baseline for a business task
Session	The current model configuration and Session-level policy	Keeps one concrete task on its selected path for later model requests

When a Session is created from an Agent that has a model configuration, xAgent expands that configuration into the new Session's runtime metadata. Later model requests use the Session's current model configuration. A Session can also select a model configuration independently, which is useful for a one-off confidential task that does not justify a new Agent.

This allows capability isolation and model-path isolation to be designed together. A confidential-material Agent can use an internal model by default and expose only the Skills and Tools needed for that job, while a general Agent can retain an external model and its own working capabilities.

A Configuration Flow You Can Review

1. Configure Two Model Classes Instead of Replacing the Default

Prepare at least one general model configuration and one internal model configuration. The internal model can point to a company-operated OpenAI-compatible service, a private model gateway, or another Provider controlled by the organization.

Test both connections and accurately declare chat, file, vision, streaming, and Tool-calling capabilities. Capability switches must describe the real model; turning them all on for convenience produces unreliable tasks.

See Model Configuration and Model Requirements for the fields and connection checks. If the server, HTTPS, access controls, and runtime environment are not ready, first complete self-hosted AI Agent deployment.

2. Create a Dedicated Agent for Restricted Work

When creating a confidential-material Agent, define at least four things:

Choose the internal model configuration as its default.
Bound the business scope and expected output in its role instructions.
Attach only the Skills and Tools required for the task.
Do not put passwords, API keys, or raw confidential material in the Agent description.

This turns “which model should I use for sensitive material?” from a one-off user decision into a reusable task entry point. See Agent Management for how entries, personal scope, and public scope are managed.

3. Keep a Task-Level Choice at the Session Layer

Session-level model selection is useful when:

A general Agent needs to handle one restricted item, so the new Session starts with the internal model configuration.
A later stage of a task genuinely needs a different model capability, after the material boundary has been reviewed.

A model switch takes effect on later model requests. It does not rewrite a request already sent to a model or a Tool call already completed. See how models, Skills, and prompts switch during a task for that runtime boundary.

Verify the Runtime Route, Not Just the Configuration Screen

An "internal" label in the configuration screen is not proof that routing is correct. Before release, run an auditable test with material that contains no real sensitive information:

Create a new Session with the confidential-material Agent and submit material containing a unique test marker.
Confirm the model configuration actually used by the Session in xAgent runtime records.
Confirm that the internal model gateway or self-hosted model service received a request with the same test marker.
Inspect the external Provider gateway, egress proxy, or firewall logs and confirm that no matching request appears.
Repeat the test for attachment handling, Tool calls, sub-sessions, and follow-up prompts, not just the first chat turn.

Record the test time, Session ID, model configuration name, internal gateway request ID, and network-audit result. This proves which route a real task used instead of merely describing which route it should have used.

The Current Boundary: Default Routing Is Not Enforced Data Residency

This distinction matters. An Agent's model configuration is carried into a newly created Session as its default, and the Session can adjust the model for later work through Advanced Settings. Agent- or Session-level selection therefore establishes clear default Provider paths, but it does not alone prove that a user can never move a task to an external model.

An internal Provider for model requests also does not mean that all data automatically stays inside the company:

MCP servers, Tools, Connectors, or network requests can send arguments and results to external systems.
File-capable models may upload files to the selected Provider, and the internal model service itself must be inside a controlled network.
Other system roles, automated tasks, and integrations need their own model and network review.
Approval decides whether xAgent performs an action; it does not replace external-system permissions or corporate network controls.

For restricted data, put model routing inside a fuller control set: a model allowlist or lock for restricted Agents, a minimal Tool set, outbound network controls, approvals for external actions, Provider and gateway audit logs, and an item-by-item review of Connectors and MCP servers. See AI Agent approval and safety controls for the current role and limits of approval.

When You Can Say Confidential Data Stays Inside the Company

Use that stronger statement only after all of the following are verified:

A sensitive Session cannot select an unapproved external model configuration.
Every model, file service, and background task that can process the material is internal or has an explicit data-processing agreement and egress restriction.
Tools, MCP servers, Connectors, and network access are restricted or approval-gated according to data classification.
The internal model gateway, network egress, and task records provide traceable routing evidence.

Until then, the accurate claim is: the model requests for this Agent or Session are routed to an internal Provider by default. That is useful capability isolation, but it should not be presented as a complete data-loss-prevention system.

Frequently Asked Questions

Is a model configuration the same as a Provider?

No. A model configuration is the stable xAgent name used to select a model. It contains the Provider type, service address, credential, and capability details. An Agent or Session selects the model configuration, and the server resolves the final Provider client.

How do I create an AI Agent that defaults to an internal model?

An administrator first creates and tests an internal model configuration. Then create or copy a personal or public Agent for restricted work in Agent Management, choose that configuration as its default model, and retain only the Skills and Tools required for the task. Create a new Session from that Agent and verify its route with test material that contains no real sensitive information, using the internal gateway and egress logs. See Agent Management for the general creation flow and Model Configuration for the model fields.

Does choosing the confidential-material Agent automatically keep every piece of data in the company?

It starts the Session with that Agent's internal model path, but you must also review whether the Session can switch models and which Tools, MCP servers, Connectors, file capabilities, and egress paths are involved. Model routing alone does not replace complete data-residency controls.

Can a Session switch models while it is running?

Yes. After a new Session model configuration is saved, later model requests use it; a request already in progress is not replaced midway. Sensitive work that must not switch needs an additional model lock and permission control.

Continue Reading

AI Agents vs. AI Automation: Differences, Use Cases, and When to Use Each

coffee — Sun, 02 Aug 2026 15:59:11 +0000

AI automation follows predefined triggers and steps. An AI agent receives a goal, examines context, chooses tools and next steps, and adapts based on results. Use automation for stable, repetitive, high-volume work. Use an agent for variable, multi-step work that requires interpretation. In production, the strongest design is often hybrid: the agent handles understanding, planning, and exceptions; deterministic systems perform sensitive actions; and people approve high-risk changes.

This is not just a product definition. We ran a controlled project-reporting task in xAgent and retained the persistent plan, task progression, deletion approval, generated artifacts, independent inspection, and repair plan. The central finding was simple: an agent can resolve work that is difficult to predefine as a workflow, but “task complete” is not the same as “result verified.”

AI Agents vs. AI Automation at a Glance

Dimension	AI automation	AI agent
Input	Stable events, forms, or records	A goal, natural language, and varied context
Path	Every step and branch is predefined	The agent chooses steps and tools within permissions
Change handling	Uncovered cases normally enter an exception path	Can interpret new cases and revise its plan, but may judge incorrectly
Output	Predefined fields or deterministic actions	Documents, recommendations, tool calls, and follow-up plans
Failure modes	Rule errors, integration failures, or invalid input	Also includes misreading, omission, unsupported inference, and false completion claims
Validation	Assert fields, status codes, and workflow outcomes	Check sources, process, artifact structure, and semantic accuracy
Cost	Usually low and predictable per run	Varies with model reasoning, context, and repeated tool calls
Control	The workflow itself defines the boundary	Requires permissions, workspaces, approval, audit, and deterministic tools

AWS's official comparison similarly describes automation as predefined, fast, consistent, and predictable, while agents add reasoning, adaptation, and decision-making. The operational question is not which label sounds more advanced. It is whether the task can tolerate uncertainty in its path and result.

What Is AI Automation?

AI automation embeds model capabilities inside a known process. A support workflow might classify an incoming ticket, extract fixed fields, apply routing rules, and write the record to a selected queue. A model may perform one step, but people still define the trigger, sequence, write targets, and failure handling in advance.

Automation is usually the better choice when:

Input structure and business rules are stable.
The same action runs at high volume.
Every branch can be described and tested ahead of time.
Output must conform to exact fields, ordering, or timing.
The system must not let a model change the execution path.

Its limit is equally clear. When two sources conflict, information is missing, or the user's goal needs reinterpretation, a workflow can only run an exception branch someone already designed. Without that branch, it does not invent a reliable response.

What Is an AI Agent?

An AI agent is defined by a goal-driven execution loop rather than a chat interface: inspect the goal and context, form a plan, discover available capabilities, call tools, examine results, and choose what to do next. xAgent places Agents, Skills, Tools, MCP, Connectors, workspaces, and approvals in one server-side task environment. Capabilities can be loaded on demand, but knowing a tool exists does not mean the user has authorized it or that approval can be bypassed. See dynamic capability discovery and approval and safety controls for those boundaries.

Agents fit work where:

Input spans documents, tables, and natural-language requirements.
Later steps depend on what earlier steps discover.
The task must distinguish facts, conflicts, risks, and missing information.
The goal is clear but the full path cannot be enumerated in advance.
A person or program can inspect the result.

The same model judgment that creates adaptability also creates new failure modes. An agent may generate a structurally plausible report that overstates the evidence. It may say it validated a file without actually parsing it. This is why an agent cannot replace validators, access control, or approval policies.

When Should You Use Each Approach?

Ask five questions before choosing a product:

Can the path be enumerated in advance? If yes, start with automation. If not, consider an agent.
Can the result be checked? High-risk work without a reliable acceptance test should not be delegated to an autonomous agent.
Can failure be recovered? Retryable, reversible work with a human takeover path is a better agent candidate.
Where does change occur? A parser or rule may handle format variation. Changes in meaning and next action are where an agent adds more value.
Does the task affect the outside world? Deletion, delivery, payment, publication, and business-data changes should pass through deterministic tools and approvals, not prompt text alone.

The weakest agent candidates have stable rules, high throughput, identical expected outcomes, or irreversible failure. Adding model judgment to those tasks increases cost and uncertainty without adding useful adaptability.

Why Production Systems Are Often Hybrid

“Agent or automation” is too simple a choice. A stronger production architecture normally has three layers:

Layer	Owns	Does not own
Agent	Goal interpretation, evidence comparison, planning, exception handling, and proposed actions	Permission bypasses or treating natural-language claims as verification
Deterministic system	Format parsing, API execution, structural validation, retries, and state recording	Semantic judgment or explanation of unforeseen cases
Person	High-risk approval, conflict resolution, and final acceptance	Manually repeating every routine step

This is consistent with the NIST AI Risk Management Framework: trustworthy use depends on risk-management practices throughout the design, use, and evaluation of AI systems. Governance is not a sentence in a prompt. It is a set of inspectable controls.

A Controlled xAgent Workflow

We prepared two fictional but internally coherent project sources: weekly meeting notes and a project-status CSV. The Agent had to generate a Markdown weekly brief and a seven-column action-items CSV while following three constraints:

Do not invent owners, dates, progress, causes, or decisions.
When sources disagree, show both claims and label the item as needing confirmation.
After validating the outputs, delete a disposable draft through the existing approval policy.

This test does not rank models or claim to represent every agent. It observes one concrete boundary: how agent judgment and deterministic controls interact when a task includes multiple sources, a persistent plan, file artifacts, and a consequential action.

1. The Agent Created and Advanced a Persistent Plan

The Agent called plan_create and established a six-step plan. The interface retained completed, current, and not-started tasks. Each task_complete call advanced focus to the next item. This differs from merely writing “Execution Plan” in a chat response: plan state persists as part of the Session and remains visible during long-running work.

2. Deletion Entered Approval Instead of Trusting Prompt Text

When the Agent tried to delete the uploaded disposable draft, fs_delete_files did not run simply because the prompt said deletion was allowed. The Session entered waiting_approval, displaying the target file, risk level, and approve/reject controls. The original tool call resumed only after the user approved it.

The prompt expresses intent; the approval policy decides whether an action may execute. They belong to different layers. The long-running task guide explains the waiting and resume behavior in more detail.

3. The First Completion Still Failed Independent Acceptance

The Agent initially reported that both files had been created and validated. We did not treat that sentence as evidence. We reopened the Markdown and imported the action-items file with an actual CSV parser. Four defects emerged:

A conflict explanation contained an unquoted comma, so the seven-column CSV parsed as eight columns.
One row omitted an empty field, shifting status and dependency into the wrong columns.
The Markdown date contained the wrong dash character.
The executive summary made an unsupported “on track” claim, and the brief did not contain the requested action-item table.

This is one of the most important distinctions between agents and traditional automation. A workflow can assert that a tool returned success; an open-ended artifact still needs structural and semantic acceptance tests. An agent's completion claim cannot verify itself.

4. The Defects Entered a New Persistent Repair Plan

We sent the exact defects, correct field mapping, and acceptance criteria back to the same Session. The Agent had to create a new persistent repair plan before editing the files in place. It separated CSV inspection, repair, parser validation, Markdown inspection, repair, and verification into distinct tasks.

After repair, the CSV parsed as A1:G6: one header row, five data rows, and seven columns in every row. The two conflicting dates remained in one field; unassigned owner and due-date values remained empty. We separately reopened the Markdown and checked its date, summary, conflict table, and visible action-item table.

The value of this loop is not that the agent was perfect on its first attempt. It is that defects became explicit tasks, persisted through a repair process, and were checked again.

Cost, Reliability, and Control Trade-offs

An agent is not a universally superior automation layer. It moves interpretation and path selection from people into a model, which adds model calls, context, retries, and acceptance checks. The more open the path, the less predictable cost and latency become.

Reliability also cannot be judged from one final answer. A production acceptance process should cover at least:

Source integrity: Did the Agent read all inputs and separate facts, conflicts, and missing information?
Process state: Did it really create a plan, call tools, and advance tasks, or only narrate those steps?
Structural correctness: Can real parsers read the CSV, JSON, tables, and documents?
Semantic correctness: Does every summary claim have support, without invented owners, dates, or conclusions?
Action boundaries: Did deletion, delivery, and external writes pass through permissions and approval?
Recovery: Can the Session retain context, original calls, and intermediate artifacts after a failure?

Decision Checklist

Use this checklist before selecting automation, an agent, or a hybrid design:

Are the steps stable enough to draw as a workflow?
Does input variation affect format, or meaning and intent?
Is there a programmatic acceptance test?
Is failure reversible, and can a person take over?
Which steps must remain deterministic?
Which actions require user or administrator approval?
Do you need persistent plans, tool calls, sources, and artifact records?
What is the business cost of one model error?

If most steps can be specified in advance, begin with automation. If the core difficulty is interpreting varied evidence, choosing next steps, and handling exceptions, add an agent. If the task combines judgment with external side effects, a hybrid design is normally the right boundary.

Frequently Asked Questions

Are AI agents better than automation?

No. Automation is normally better for stable, high-volume, rule-driven work. Agents handle variable paths and semantic judgment, but add cost, latency, and uncertainty.

When should you not use an AI agent?

Do not add an agent to irreversible, untestable, strictly deterministic work, or to a task that simple rules already complete reliably. Higher-risk actions need deterministic tools, permissions, and human approval.

Can AI agents and workflow automation work together?

Yes. This is a common production pattern. The agent interprets goals, plans, and handles exceptions; the workflow validates fields, calls APIs, retries, and records state; people approve higher-risk actions.

Do AI agents replace RPA or traditional workflows?

Not as a whole. An agent may decide when to invoke an existing workflow or handle inputs the workflow does not cover. Batch execution, deterministic actions, and interface operations may still belong to RPA or workflow systems.

How do you keep an AI agent under control?

Do not rely on prompting alone. Design data visibility, tool availability, workspace scope, external connections, approval policies, task state, and result validation as separate layers, and retain an auditable execution record.

Originally published at xagent.xiagaogao.com.

Learn more in the xAgent documentation.

xAgent 0.0.5.beta Is Available

coffee — Wed, 29 Jul 2026 12:22:36 +0000

xAgent 0.0.5.beta Is Available

xAgent is a server-side, multi-user AI Agent work portal built for completing real tasks, not just conversations.

Administrators prepare models, Skills, Tools, MCP servers, Connectors, and safety policies. Users then describe the goal, provide materials, and confirm important actions when needed. Tasks continue on the server even when the user's device is offline.

This release focuses on runtime and service-boundary consolidation rather than adding more surface-level features:

Clarified responsibilities across runtime flows to reduce maintenance and troubleshooting complexity;
Prepared the codebase for progressively consolidating Connectors, installation, and release workflows in the main repository;
Continued strengthening existing session, approval, Skill, Tool, MCP, Connector, and workspace-isolation capabilities.

The goal is to make xAgent a tool that gets work done. It can chat, but when a task involves files, external systems, approvals, or long-running execution, it should keep moving the work forward.

xAgent is still in beta. It is intended for people exploring self-hosted deployment, multi-user AI Agents, custom Skills, and IM Connector integrations.

Documentation: https://xagent.xiagaogao.com/en/

Feedback is welcome:

Which recurring tasks would you most like an Agent to run continuously?
Where do you get stuck most often: deployment, model configuration, or Connector setup?
Which Skills, MCP integrations, or Connectors would be most useful?
Report an issue or share a feature request: https://github.com/coffeehc/xagent-releases/issues/new

Beyond Chat: Building a Task-First AI Agent Platform for Teams

coffee — Wed, 15 Jul 2026 17:44:23 +0000

Most AI agent products begin as a chat interface. That is useful, but conversation is not the same thing as completing work.

xAgent is built around a different question: what does an AI agent need in order to receive a task, work over time, use the right capabilities, protect data, and hand back a usable result?

The answer is more than a model and a prompt. It is an operating environment for agents.

Task-first, not chat-first

xAgent can answer questions, but it is not positioned as a companion product. Its primary job is to help a person or a team complete work: organize materials, produce files, research a topic, prepare a response, coordinate follow-up, or run a recurring workflow.

An agent session has a task, supplied materials, a workspace, available capabilities, and an expected result. This gives longer work a clearer lifecycle than an open-ended conversation.

Run agents on the server

xAgent is deployed as a server-side binary. Users access it through the web UI or IM connectors, rather than installing a separate agent on every computer.

That matters for real work:

Tasks can continue while a user's device is offline.
Files and results remain in the server-side workspace.
A user can submit or follow up on work remotely from an available IM channel.
Deployments can keep data in infrastructure controlled by the team. With local models, the full data path can remain private.

Multi-user by design, with workspace isolation

A multi-user agent system needs more than separate folders. xAgent uses a virtual file system layer above the host file system. What a user or that user's agent session can list, read, or write is checked through that layer.

A physical workspace can contain many files while a specific user or session sees only the permitted portion. Some system files are never exposed, even when broader workspace access exists. This creates a practical boundary for shared server deployments without asking a language model to act as the access-control system.

Capabilities should be discoverable, not permanently stuffed into context

Agents need Skills and Tools, but loading every available capability into every prompt wastes context and makes behavior harder to control.

xAgent starts sessions with a small set of discovery and loading capabilities. When work requires something else, the agent can find and load the relevant Skill or Tool. Resident capabilities configured in Advanced Settings remain explicit; dynamically discovered capabilities are intentionally not treated as permanent configuration.

This keeps the default session focused while allowing the agent to expand its working capability when a task actually needs it.

Change what matters while work is running

Long-running tasks are rarely perfect on the first try. xAgent allows runtime adjustments to prompts, Skills, and models without discarding the session. This is useful when a task needs stronger reasoning, a different specialized Skill, or a tighter instruction after seeing intermediate results.

The goal is controlled iteration: keep the work and its context, adjust the execution path, and continue.

Connect the agent to the systems where work already happens

MCP gives an agent a way to call external tools on demand. Connectors solve the complementary problem: they can receive messages and events from outside systems and deliver them into xAgent.

Current released connectors support WeChat, Telegram, and mainland China Feishu. They make it possible to use existing communication channels as task entry points while keeping connector credentials and external login state inside the connector service.

Safety is part of the workflow

An agent that can act on external systems needs meaningful control boundaries. xAgent supports approval policies for sensitive operations. Administrators can define a public baseline for the deployment, while advanced users can refine their own policy further.

This keeps routine work moving without making every external action an unchecked model decision.

A practical starting point

Start small: deploy xAgent on a server, connect a model that supports tool calling, give one agent a clear task, and add a Connector only when an external channel is useful. Teams can then build reusable Skills, promote stable ones to the public library, and keep improving them through real work.

xAgent is currently a beta binary release, with free use for up to five users. The product is designed for private deployment rather than a hosted SaaS model.

Documentation: https://xagent.xiagaogao.com/en/

Server installation: https://xagent.xiagaogao.com/en/docs/deployment/server-install/

GitHub releases: https://github.com/coffeehc/xagent-releases