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 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.

This path lets one task continue after Tool Calls, wait before a high-impact action, compress a growing context, exit when the user interrupts it, and resume after a service restart when valid persisted facts exist.

This AI agent context-management and execution loop was further improved in 0.0.10.beta. This article focuses on how each request is assembled, suspended, compressed, and recovered.

Comparison Baseline and Scope​

For an architecture-level decision and use-case comparison, start with DeepSeek Harness vs. xAgent: Choosing an Agent Harness Architecture. This article continues with runtime execution, pausing, and recovery.

This article continues to use xAgent 82f3a1f6 on August 16, 2026, and DeepSeek Harness 47f94385 on August 13, 2026, as its factual baseline. DeepSeek Harness was still a developer preview at that commit. The comparison covers published code and documentation, not inferred future stability.

Both systems implement a Harness layer, but their fact models differ:

• DeepSeek is composition-first and event-log-first.
• xAgent is fact ownership-first and owner-state-first.

These are not two names for the same implementation. DeepSeek composes capabilities through a Cordis plugin tree and uses one event log for reconstruction and replay. xAgent divides state across a fixed owner spine and persists long-task facts for recovery across requests.

Side-by-Side: Similar Loops, Different Fact Boundaries​

Both designs recognize that one model response is not a complete Harness and one successful Tool result does not complete the user's objective. Their main disagreement is what counts as a recoverable fact and where extensions attach.

Why DeepSeek Has Stronger Exact Replay​

The DeepSeek architecture documentation states a direct invariant: Model-visible means logged. User messages, stream chunks, assistant messages, Tool calls and results, request headers, and the effective prompt, tools, and model config can be reconstructed from the Session log.

Fork, resume, transcripts, telemetry, and UI replay can therefore derive from one event stream. Compaction does not delete the original facts. It replaces a range on the model-visible surface with a summary while retaining the raw log and replacement evidence.

xAgent does not depend on one exact event stream to reconstruct every request. It assembles current context from several fact owners. This gives DDD responsibilities a clearer shape and allows an owner to correct its own state, but the evidence for exactly which prompt, Tool schema, and owner fact versions entered a historical request is less direct than in DeepSeek.

That is an architecture judgment. It does not mean xAgent lacks persistence, or that a single-log model automatically fits every business fact.

Current xAgent: One Runner per Session​

User messages, Connector events, Session collaboration input, and approval decisions can arrive close together. Brain first acquires SessionEngine's single runner, then consumes input, events, guidance, and pending state in order. If a runner already exists, a new entry records a wake request. When the old runner releases and executable work remains, Brain acquires it again and continues draining.

This serialization targets the same class of problem as DeepSeek's inbox and phase, but the implementations are not equivalent.

Every Model Call Is Reassembled from Owner Facts​

AgentService does not keep a private, mutable copy of Session History. Before each model call, SessionEngine assembles the request from current facts, including:

• Session-wide and current-phase goals;
• raw History, checkpoints, and the current compression boundary;
• loaded Skills, Tool schemas, and call policy;
• Memory, resource references, attachments, and workspace context;
• current model configuration, Prompt, and runtime policy.

After a Tool result becomes stable, the next model call is assembled again. Newly committed Tool results, capability changes, pending consumption, and context maintenance enter the next round without creating a second drifting state inside AgentService.

This differs from DeepSeek's strategy of deriving model History from the log and recording a complete request header. DeepSeek prioritizes exact request replay; xAgent prioritizes assembling the next request from each owner's latest facts.

A Fixed ToolService Governance Chain Is Not Missing Capability​

A model call can produce final text or multiple Tool Calls. xAgent currently executes those calls one by one in model order. Each call passes through centralized governance, and only stable assistant/Tool pairs are committed:

Model emits a Tool Call
  -> Resolve the Tool available to this Session
  -> enabled / readiness / schema checks
  -> approval and secret handling
  -> workspace execution lease / runtime execution
  -> result normalization and secret redaction
  -> commit assistant tool_call + tool_result as a pair
  -> reassemble the next model request

DeepSeek's Tool pipeline provides waterfalls, monotonic guards, wrappers, post hooks, and finalization. parallel calls may overlap in a bounded pool while results still commit in the model's original order. Its Tool extension model is more flexible.

xAgent has a more fixed extension shape but more centralized governance facts. A non-plugin pipeline does not imply missing path, approval, secret, workspace, or result-normalization controls. Serial-safe execution is also a reasonable default. A concurrency-safe classifier and model-order result commit become worthwhile only when real performance evidence shows Tool concurrency is a bottleneck.

In the customer-support reporting run, the timeline records model output, file writes, task completion, and the next task start as consecutive rounds of one long task:

The final HTML remains independently inspectable. Users validate the KPI values, charts, and conclusions rather than treating one successful file-write call as proof of completion:

Approval: Live Promise Versus Durable Pending State​

DeepSeek's approval seam asks inside an active turn, waits for an answerer to return a closed outcome, and appends approval/asked and approval/decided as an audit pair. A missing or invalid answerer fails closed.

When xAgent requires approval, AgentService hands the blocked Tool Call, preallocated result identity, and PendingRequest to SessionEngine as a RuntimeAuditUnit. The Session waits and the current execution stack exits. After Brain validates and binds the user's decision, AgentService consumes that durable pending state under a later runner and either continues the original call or commits a rejection result.

An xAgent approval is therefore neither a new task message nor only a Promise in an active stack. It is designed for long waits across requests and restarts. DeepSeek's asked/decided pair provides a more direct single-stream audit trail.

The Two Compaction Models Are Not Equivalent​

DeepSeek implements compaction as an optional capability seam. A provider generates a summary, and a replacement operation changes what later model requests see on the Session surface. The raw events, shadowed range, summary result, and model-call evidence remain in the append-only log. This design prioritizes audit, replay, and reconstruction of the model-visible surface.

xAgent Context Compression prioritizes semantic continuity and crash-safe commit. SessionEngine freezes real History and selects a legal message boundary. SummaryService produces an intermediate structured result, and SessionEngine validates and commits the checkpoint. The continuity summary preserves execution facts such as Goal, Artifact, Decision, ActiveUserRequest, constraints, open questions, and next actions.

A Tool Call and Tool Result cannot be split by a compression boundary. Session-wide and current-phase goals still come from SessionMeta; a model-generated summary cannot overwrite their owner.

Active-Turn Compaction and Restart Recovery​

One user request can produce many model and Tool rounds and exhaust context inside the same active turn. xAgent can compact sealed earlier material while retaining a continuity anchor for the current request. A checkpoint and pending compaction form a verifiable commit state before ContextStartMessageId advances; restart recovery then promotes a valid pending state or discards one whose preconditions never committed.

DeepSeek persistence preserves flushed events from a crashed turn and appends synthetic unknown / interrupted closers for unanswered Tools, an open step, and the turn, restoring a valid transcript. Its persistence documentation explicitly states that the current crash story closes an interrupted turn instead of resuming a partial turn.

xAgent focuses on a different recovery unit. After dependencies become ready, Brain reads valid recovery snapshots and uses the same runner and AgentService path to restore guidance, pending approval, active-turn compaction, and related runtime facts. It does not promise lossless replay of every external Tool. Idempotency, duplicate-request protection, and result lookup remain with the Tool and external system.

The precise comparison is: DeepSeek is stronger at log balancing, exact replay evidence, and interrupted transcripts; xAgent is stronger at resuming durable long-task business state across requests and restarts.

Subagents and Sandboxes: Adjacent Capabilities, Different Priorities​

DeepSeek exposes Subagents through replaceable providers for in-process spawn, fork, ACP, Codex, Claude Code, and other backends. xAgent uses Main / Sub Sessions, SessionEvent, and Workgroup collaboration. A receiving sub-Session gets the original request and resource references, then understands the task and prepares its own capabilities. The parent does not preselect its Skills or Tools.

Sandbox design shows the same difference. DeepSeek uses FS, Subprocess, and Sandbox seams to replace the execution world. xAgent uses:

Agent Harness
  -> ToolService governance
  -> Workspace Execution Lease
  -> ProcessSandbox
  -> file-change reconciliation

Not every Tool passes through ProcessSandbox. Remote MCP and Connector Tools have their own execution boundaries, while every Tool Call still passes through Harness history, governance, waiting, and result progression. DeepSeek is stronger in provider replaceability; xAgent is stronger in workspace fact governance. See Runtime and ProcessSandbox.

Architecture Conclusions and Optional Improvements​

Four conclusions follow from the current implementations:

1. xAgent has a complete Harness layer even without a package named harness.
2. DeepSeek has stronger exact-request replay and Tool extensibility; xAgent has stronger durable approval, active-turn compaction, and owner-state recovery.
3. Their Session facts, compaction, and crash recovery cannot be called equivalent merely because adjacent concepts share names.
4. xAgent should not copy everything-is-a-plugin for formal symmetry.

Optional future improvements include:

• formally define outer task control, Session runtime, inner Agent loop, Tool governance, and execution isolation as the xAgent Harness boundary;
• project read-only evidence for prompts, Tool schemas, model config, and owner fact versions to improve request reconstruction;
• add Tool concurrency classification and model-order result commit only when real performance demand exists;
• preserve the task relation enum, receiver self-understanding, durable approval, active-turn compaction, and owner-state correction;
• reduce SessionEngine dependency pressure through clearer owner business actions and fewer pass-through or cross-owner operations, not by turning the entire core into plugins.

These are architecture recommendations, not features claimed as already implemented.

The User Ultimately Sees Delivery Evidence​

Internal owner boundaries project into runtime states users can understand: preparing context, running, waiting for approval, compressing, interrupted, failed, or idle. At completion, the final response, Session file tree, and explicit validation results form one delivery record:

Together, the two articles describe the xAgent Agent Harness as two coordinated layers. Outer control classifies task relationships and adds capabilities; the inner loop executes, waits, compresses, and recovers. Models provide constrained semantic judgment and action proposals, while deterministic owners control facts, permissions, and state transitions.

xAgent handles that question before the business Agent loop. The original input first becomes a Session fact. One constrained semantic call then returns a task relationship together with Skill, Tool, and Memory recall terms. Brain applies a deterministic state transition, and Orchestrator adds capabilities only when the task is first established or its phase changes.

This task-understanding, AI agent tool selection, and environment-preparation path shipped in 0.0.10.beta. This article explains its responsibility boundaries and execution order inside the Harness.

Comparison Baseline: Two Harnesses, One Layer, Different Priorities​

For an architecture-level decision and use-case comparison, start with DeepSeek Harness vs. xAgent: Choosing an Agent Harness Architecture. This article continues with the current outer task-control implementation.

The factual baseline for this article is xAgent 82f3a1f6 on August 16, 2026, and DeepSeek Harness 47f94385 on August 13, 2026. At that commit, the DeepSeek Harness README still labels the project a developer preview and warns about compatibility-breaking changes. This article therefore does not treat interface stability or complete production readiness as a promise.

Both systems sit outside the model API and coordinate Sessions, context, Tools, execution, recovery, and multi-Agent work. xAgent has no package literally named harness, but that does not mean it lacks a Harness layer. Their core abstractions differ:

The DeepSeek architecture documentation emphasizes that almost everything is a plugin and that there is no privileged core that extensions must patch. xAgent retains an explicit responsibility spine:

DeepSeek: Profile / Bundle -> Cordis Plugin Tree -> Agent Loop
          -> append-only SessionLog -> Tool Pipeline -> LLM / Sandbox / Subagent

xAgent:   Channel / Connector / Trigger -> Brain -> SessionEngine
          -> AgentService -> LLMProvider / ToolService

These implementations address the same system layer, but they are not equivalent. xAgent is not a DeepSeek Harness fork, frontend, or thin wrapper.

Why a Tool Loop Is Not Enough​

Suppose a sub-Session is working on “research ComfyUI and deliver a Markdown guide.” The next message might be:

• Continue: continue the current phase.
• Convert the Markdown we just created to Word: remain within the Session's responsibility, but change the delivery phase or capability needs.
• Also check tomorrow's weather: fall outside the responsibility of this specialist Session.

Keyword extraction from only the newest sentence yields almost nothing for Continue. Rebuilding the environment for every message causes capability churn. Letting a model rewrite the goal directly would also turn semantic judgment into a second fact owner.

xAgent therefore separates the outer task-control problem into two decisions: classify the message against the current task boundary, then recall and add capabilities only when required.

Current Code Fact: How One Input Reaches the Business Agent​

At 82f3a1f6, the actual sub-Session path is:

Sub-Session receives the original message and stable resource references
  -> SessionEngine.AppendToHistory persists the original input
  -> One stateless semantic call
  -> task_relation + three recall-term groups
  -> Brain applies a deterministic task-state transition
  -> [initialize / reconcile only] Orchestrator recalls and selects capabilities
  -> SessionEngine.AddSelectedCapabilities
  -> AgentService enters the model / Tool loop

The original message is appended to Chat facts and synchronized into the Session context cache before semantic preprocessing begins. A supporting-model, retrieval, or orchestration failure therefore cannot make the user's input disappear.

This preprocess applies only to sub-Sessions. MainSession retains its coordination and routing role and bypasses task-relevance preprocessing. Approval decisions, system notifications, and attachment-only inputs with no explicit task text also bypass it.

One Semantic Call Returns Exactly Four Fields​

The task-relevance Agent is a stateless, non-streaming JSON call. Its input contains only:

• the current message text;
• stable resource references such as ref_id, protocol, filename, and media_type;
• current_task_goal;
• session_goal.

It does not read full History, receive candidate Skills, Tools, or Memory, generate a Plan, or select Orchestrator candidates. Its output must contain exactly four fields:

{
  "task_relation": "continue_current",
  "skill_recall_terms": [],
  "tool_recall_terms": [],
  "memory_recall_terms": []
}

All three recall-term fields must be non-null arrays with at most 16 items each. Terms are concise, deduplicated English phrases with a role that describes intended use. Skill and Tool terms can represent method, action, evidence, quality, domain, or artifact. Memory terms can represent entity, topic, context, preference, constraint, or decision.

There is no second model call that “extracts task essentials.” The task-understanding notice and later capability-discovery notice correspond to one semantic preprocess and the separate Orchestrator stage.

Task Relationship Is an Enum, Not Two Scores​

task_relation accepts only five values:

Brain uses no score threshold, and the model does not generate a rewritten goal. When no current-phase goal exists, the original user message becomes the task goal. On change_within_session, that original message becomes the new phase goal. Every other relationship preserves the existing goal.

The Session still distinguishes a Session-wide goal from a current-phase goal. The first represents durable responsibility; the second represents current work. Summaries, Plans, and Tasks may refer to these facts, but they do not become their owner.

Only Two Modes Invoke Orchestrator​

Only initial task setup in initialize mode or a change_within_session transition into reconcile mode enters capability preparation. Continuing, out-of-scope, and uncertain inputs do not reselect capabilities.

Orchestrator recalls three independent context groups in parallel:

• Skill candidates;
• ToolSet and enabled standalone Tool candidates;
• long-term Memory for the current user.

Recall scores are used only for candidate truncation, ordering, and debug logs. They do not enter the final orchestration Prompt and do not drive Brain's task transition. Candidates are sorted by stable references before the model sees them, so concurrent completion order cannot randomize the input.

The following customer-support reporting run shows semantic understanding, capability discovery, and orchestration. It is not a chain of three model roles or two task-semantic extraction calls:

Orchestration Adds Capabilities Without Creating a Second Fact Center​

Orchestrator consumes the aligned task, three recall-term groups, current capabilities, and recalled candidates. It returns ToolSets, Tools, and Skills to add. SessionEngine merges them atomically through AddSelectedCapabilities:

• keep capabilities already loaded;
• retain default discovery capabilities;
• add only, never remove implicitly;
• do not create a Session;
• do not rewrite task goals;
• do not select or modify the model, AgentDefinition, or a special role.

Capability removal requires an explicit unload path. Model configuration and Agent identity remain with their own owners instead of changing as a side effect of capability orchestration.

The resulting environment stays inspectable in Session settings:

The Receiving Sub-Session Understands Its Own Task​

MainSession can decide which sub-Session should own work, but the sender transfers only the original request and stable resource references. It does not preselect Skills, Tools, or an execution Prompt for the receiver. The receiving Session treats the collaboration request as its own real input and runs task understanding and capability preparation itself.

The rule is simple: the Session that executes the task is the Session that understands it. This prevents a parent Session's candidate space, stale capabilities, or inference from becoming child facts. See Multi-Agent Session Event Collaboration for the transport path.

Outer Enhancements Fail Without Blocking Execution​

If semantic preprocessing fails, xAgent preserves the persisted input, current goals, capabilities, and compression boundary, then continues into the business Agent. Orchestrator or Memory recall failure also does not clear the environment first. Existing capabilities and default discovery Tools remain available, allowing the Agent to discover more capabilities during execution.

This does not hide failures. It gives the outer enhancement a precise failure boundary: it may miss one capability preselection, but it cannot take away original input, existing task facts, or the main execution path.

Users typically see a sequence like:

Understanding task semantics
  -> Discovering Skills, Tools, and Memory
  -> Orchestrating task capabilities
  -> Applying the task environment

The final three stages do not run for a simple continuation. See How AI Agents Discover and Load Tools and Skills on Demand for runtime capability discovery.

Architecture Judgment: xAgent Should Not Copy Everything-Is-a-Plugin​

DeepSeek Harness provides strong composition for replacing model adapters, Tool pipelines, persistence, sandboxes, and Subagent providers. xAgent's strength comes from stable owners: Brain controls scheduling and task transitions, SessionEngine coordinates Session facts, AgentService owns the inner loop, and ToolService owns governance.

The useful lesson is a clear capability seam and reconstructable evidence, not converting every xAgent core responsibility into a plugin. Doing so would blur the fact owners the architecture already established.

As a future improvement, xAgent can formally document its Harness boundary and project request evidence for prompts, Tool schemas, model config, and owner fact versions. Those projections should support audit and reconstruction, never become a second source of truth. These are architecture recommendations, not features claimed as implemented here.

Next: How Aligned Work Keeps Running​

Outer task control answers “How does this message relate to the current task, and does the Session need additional capabilities?” The business Agent then enters its fixed model and Tool loop.

The next article, Inside the xAgent Agent Harness, Part 2: How Tasks Run, Pause, and Resume, compares DeepSeek's Agent Loop, SessionLog, Tool pipeline, and crash repair with xAgent's single runner, approval state, context compression, and recovery model.

We tested those boundaries in a real xAgent session. The session loaded the deep-research Skill, connected to an MCP Server containing the official Model Context Protocol documentation, called two MCP Tools, wrote a report, and reopened the report for validation. The validation step also caught an inaccurate lifecycle description in the first draft and forced a correction.

The test setup​

The task was deliberately narrow: research the difference between an AI Agent Skill, a Tool, and MCP, then save an evidence-backed report as skill-tool-mcp-verification-en.md.

The prompt added several constraints so the session could not quietly take a shortcut:

1. Create a persistent execution plan and update it as work progresses.
2. Find and load the deep-research Skill instead of merely claiming to use it.
3. Use the configured MCP Official Docs Server for the research.
4. Record the exact MCP Server, Tool names, and actual call counts.
5. Keep native xAgent Tools separate from MCP Tools in the evidence section.
6. Reopen the generated file and verify its content before completing the task.

These constraints turned a conceptual question into a runtime test. Each part had to leave evidence in the session history.

A plan is not a Skill, and a Skill is not a Tool​

The session began by calling plan_create. It then found deep-research with skills_find and loaded it with skills_load. The Tool result returned deep-research in accepted_skill_ids, which is stronger evidence than a message saying, “I will use a research Skill.”

Three different responsibilities are already visible:

• The plan records the current sequence and progress of this particular task.
• The deep-research Skill supplies the research method, evidence rules, and quality checks.
• plan_create, skills_find, and skills_load are Tools that perform concrete runtime actions.

The Skill can tell the agent how to investigate a question and what a good report must contain. It does not create a plan, search a registry, or change session state by itself. Those effects require Tools.

This also explains why mentioning a Tool in a Skill does not make the Tool available. The current session must still be able to discover and load that Tool, and the user must still have the required connection and permission.

Discovering an MCP Tool is not the same as calling it​

The session next discovered two capabilities from the configured MCP Official Docs Server:

• search_model_context_protocol searched the official documentation corpus.
• query_docs_filesystem_model_context_protocol read the relevant documentation pages returned by those searches.

After selection, the session actually invoked both Tools. The final audited count was six search calls and two document queries. One of the later searches was part of the repair pass that checked the protocol's statelessness against the current architecture page.

The distinction matters because the same session also called tools_find and tools_select. Those are native xAgent Tools used to discover and load capabilities. They participated in finding the MCP Tools, but that does not make them MCP Tools.

For an agent, both native and MCP-provided capabilities appear as callable Tools. For an operator, their source determines who owns execution, authentication, connectivity, data access, and failure handling.

The first report was not accepted​

The first generated report contained the required sections, but its validation was only partial. More importantly, it described MCP as a “stateful session-based protocol.” That wording was too broad and did not match the current official architecture documentation.

The repair pass reopened the full artifact, checked the relevant official source, and changed the lifecycle descriptions:

• MCP is described as a stateless protocol. Each request carries the protocol version and relevant capabilities, while clients and transports may maintain connections when needed.
• A Tool is invoked per call; any retained state or side effect depends on the Tool implementation.
• The Skill lifecycle is stated specifically for this xAgent run: deep-research was loaded into the current Session context. It is not presented as a universal Skill runtime rule.
• An MCP Tool is explicitly described as a Tool exposed by an MCP Server, not as a separate capability category.

The repaired artifact then passed ten checks covering the direct answer, comparison table, execution example, Skill identity, MCP Server identity, Tool names, call counts, official findings, source links, runtime evidence, and FAQs.

This is a useful operational lesson: a successful file-write call proves that a file was written. It does not prove that the report is accurate.

What each concept owns​

The runtime evidence makes the boundaries easier to state without relying on analogy.

Tool: the executable action​

A Tool is a capability with a defined purpose and input. Reading a file, querying a database, running a calculation, creating an artifact, and sending a message are all Tool-shaped operations.

xAgent can make Tools available from several sources:

They can look similar to the model, but they do not have the same operational boundary. A database query served by MCP can involve remote credentials and network access; a native file Tool may stay inside the xAgent workspace; a Connector Tool may act through a user's enterprise identity.

Skill: the reusable method​

A Skill packages the way a task should be approached. It is a good place for research steps, decision rules, output requirements, stop conditions, templates, and reference material.

The official MCP guide to Agent Skills describes Skills as portable instruction sets that give agents domain-specific expertise. In this run, deep-research supplied the method. The Tool calls still performed the searches, reads, and file operations.

A one-off file read rarely needs a Skill. Recurring work such as contract review, incident analysis, competitive research, or release checks usually benefits from one because the method and acceptance criteria need to survive beyond a single prompt.

MCP: the integration protocol​

The current MCP architecture overview defines a Host, Client, and Server model. An AI application acts as the Host and creates a Client for each connected Server. Servers can expose three core primitives:

• Tools: executable functions the AI application can invoke;
• Resources: data sources that provide context;
• Prompts: reusable templates for model interactions.

The current protocol uses discovery to learn what a Server supports and structured requests to invoke a Tool. MCP standardizes that exchange; it does not decide whether a user should have access, whether sensitive input may leave the organization, whether a write requires approval, or whether returned data is correct.

In short, the run looked like this:

User goal
  -> deep-research Skill: research method and acceptance rules
  -> native xAgent Tools: plan work and load capabilities
  -> MCP Client: connect to the MCP Official Docs Server
  -> MCP Tools: search and read official documentation
  -> native xAgent Tools: write, reopen, and validate the report

Where the combination helps​

Suppose a team needs to analyze an internal sales workbook, add public market data, and publish a sourced report.

The Skill can define the metrics, anomaly rules, evidence standard, and report structure. Native file and spreadsheet Tools can process the internal workbook. An MCP Server can provide a market-data Tool. After review, a Connector Tool can send the approved summary through the user's existing enterprise identity.

Those components can change independently. Replacing the market-data provider does not necessarily require rewriting the analysis method. Tightening the report standard does not require rebuilding the MCP Server. Separating the responsibilities makes permissions, testing, and incident ownership much easier to reason about.

Frequently asked questions​

Is an MCP Tool different from a normal Tool?​

It is still a Tool. The difference is its source and runtime ownership: an MCP Server exposes it through the protocol instead of the xAgent Runtime providing it natively.

Does loading a Skill automatically load its Tools?​

No. A Skill can describe the capabilities a workflow needs, but the current Session must still discover and load the matching Tools. Connection state, user permissions, and approval policy continue to apply.

Does a successful Tool call mean the task is complete?​

Not necessarily. It proves that one operation returned successfully. The workflow must still verify the resulting file, external state, evidence quality, and acceptance criteria. The correction in this test is a concrete example of why that final check matters.

Continue with xAgent​

• Create, test, and publish a Skill
• Inspect Tool sources, permissions, and results
• Understand dynamic Tool and Skill discovery
• Configure approval boundaries for Tools

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​

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:

1. Can the path be enumerated in advance? If yes, start with automation. If not, consider an agent.
2. Can the result be checked? High-risk work without a reliable acceptance test should not be delegated to an autonomous agent.
3. Can failure be recovered? Retryable, reversible work with a human takeover path is a better agent candidate.
4. 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.
5. 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:

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:

1. A conflict explanation contained an unquoted comma, so the seven-column CSV parsed as eight columns.
2. One row omitted an empty field, shifting status and dependency into the wrong columns.
3. The Markdown date contained the wrong dash character.
4. 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.