A manager uploads a corporate PowerPoint template. An Agent analyzes the PPTX, interprets its structure, builds a reusable mold, and validates the result. The onboarding job can take around ten minutes. In a proof of concept, a successful run makes the approach look straightforward. In a service, the harder question is what happens if the worker fails during validation after the expensive work is already done.
The Agent may be capable of finishing the task. The system still needs to remember what the task is, what has succeeded, and what can safely happen next. That is where an Agent Run and a Business Job become different things.
The ten minute task belongs to the administrator
Companies often have PowerPoint formats they have used for years: covers, contents pages, recurring layouts for data, and established relationships among tables, charts, body text, and callouts. In the Fetchdoc example, an administrator registers a raw PPTX once and turns it into a reusable mold. Later, an ordinary user applies fresh data to that mold to generate a document.
Those are two different paths. Administrator onboarding follows raw PPTX → structural analysis → semantic interpretation → reusable mold creation → validation → ready. It can take roughly ten minutes and use substantial compute and resources. The recurring user path follows new data → existing mold → generated document, and is much faster because the structural work has already been done.
The ten minute wait in this article is therefore the initial mold creation job. It is not a wait imposed on every document request.
This pattern extends beyond templates. Data imports, large document analysis, knowledge indexing, report template onboarding, and batch evaluation all put occasional heavy administrative work on a different clock from a user’s real time request. Adding an Agent to such a workflow raises an operational question: how does the service own work that takes a long time and may fail partway through?
A successful Agent run is only the first test
A proof of concept can follow one uninterrupted path: upload the PPTX, analyze it, build the mold, validate it, and return the result. Running a service means accounting for the seventh attempt that does not finish cleanly.
Suppose PPTX analysis has completed, an intermediate structural artifact exists, and mold creation is nearly done when the worker fails during final validation. Where should a new attempt begin? Can the system trust the artifact it already produced? Can the administrator find the job after closing the browser? If the worker restarts, how does the system know what was completed?
A single long request leaves those answers tied to temporary execution machinery. The HTTP connection can drop, a reverse proxy can time out, an external AI provider can be slow, a worker can restart, or the administrator can submit the same request again. Keeping an Agent occupied for ten minutes does not, by itself, preserve the business work for ten minutes.
The question I found more useful was: how does the system avoid losing the work while it is in progress?
The Business Job outlives the Agent Run
An Agent Run is one execution attempt. It can fail, restart, or be replaced by another worker or runtime. A Business Job is the administrator’s request: analyze this raw PPTX and make a reusable mold. That request needs an identity, a record of its progress, and a way to find artifacts and decide which operations may run again.
This changes the center of the design. The Job owns durable business facts; the Analyzer, Agent, Renderer, and Validator perform bounded pieces of execution. A worker can disappear without taking the Job’s identity or verified evidence with it.
For this kind of workflow, durability comes from being able to recover the work after an Agent Run ends. It does not require one Agent process to remain alive throughout onboarding.
State records what the business has secured
A mold onboarding lifecycle might read: RECEIVED → ANALYZING → STRUCTURE_READY → MOLD_BUILDING → VALIDATING → READY.
These states should describe durable facts, rather than which prompt an Agent happens to be processing. STRUCTURE_READY should mean that structural information has been extracted from the raw PPTX, stored, and validated. If the Job has reached MOLD_BUILDING, the application should be able to proceed without repeating the completed analysis.
That distinction affects cost as well as reliability. In a long AI workflow, the most expensive stage is not necessarily the last one to run. A validated artifact gives recovery a starting point: repeat the unit that failed, while retaining completed work whose evidence is still valid.
Retry, Resume, and Replay answer different questions
I initially called every response to failure a retry. In operation, three different actions matter.
- Retry repeats a failed operation. If a validation API fails temporarily, the application may call that validation operation again.
- Resume continues after a durable checkpoint. If PPTX analysis and mold creation succeeded but validation failed, the application retains the completed work and continues from there.
- Replay rereads the current state, events, and artifact evidence, then determines which action is permitted now. It is a decision from saved evidence, not an instruction to rerun every earlier side effect.
Separating these actions makes recovery rules explicit. Which operation is safe to call again? Which stage is already complete? Which state transition needs to be evaluated again? The application can define those answers as a deterministic contract instead of asking an Agent to decide from natural language on every recovery attempt.
Waiting is part of the lifecycle
Long running work also has periods when nothing is actively executing. An external provider may be preparing a result, a worker result may be pending, or the Job may need to pause until resources are available. From the perspective of a synchronous request, the absence of a response can look like failure. For a durable Job, WAITING can be an ordinary state: RUNNING → WAITING → WAKE → RUNNING.
The system needs to store what the Job is waiting for, the condition that will wake it, and the state from which it should continue. It does not need to hold a process open merely to represent that wait. A Job that is not using CPU is not necessarily a Job that has failed.
The hardest failure may look like an ordinary timeout
Consider a mold artifact save that succeeds on the server. Before the success response reaches the caller, the network times out. The server has completed the operation; the caller sees a failure. Repeating the request without checking its outcome could create the artifact again or duplicate a downstream side effect.
Idempotency addresses that ambiguity. Given the same canonical input and Business Job identity, the application needs a way to find and reuse the successful result, or establish that the same side effect has already occurred. Retry safety depends on identifying the business operation and its recorded effects, rather than choosing a retry count.
At this point, an Agent runtime is part of the application architecture. It participates in work whose identity, state, and side effects must remain understandable after a particular execution attempt has ended.
The proof of concept tests the boundaries
I do not treat a particular proof of concept stack as the enterprise answer. Tools such as n8n, FastAPI, and PostgreSQL can make an orchestration flow, application API, durable database, and Agent worker quick to assemble and inspect. The transferable part is the division of responsibility:
- Admission and orchestration handle when a Job starts and when it may continue.
- The application boundary owns permitted state transitions and business policy.
- Durable storage preserves the Job, its state, events, and artifact evidence.
- The Agent and other workers perform bounded execution.
An enterprise implementation could use Step Functions, Temporal, Durable Functions, messaging infrastructure, domain services, an RDB, or an event store in a different combination. My aim with a fast proof of concept is to test an executable architecture sketch, then carry its contracts and responsibility boundaries into the target architecture.
A PowerPoint task reveals a wider workload pattern
Fetchdoc’s mold onboarding makes the problem concrete, but the same shape appears in large document research, contract analysis, batch classification, complex report generation, code generation with validation, multi-system reconciliation, and asynchronous media generation. A request can contain AI steps and deterministic steps, depend on external systems, produce intermediate artifacts, spend time waiting, and include side effects that must not be duplicated.
This is the serving problem for long running Enterprise AI workloads. Agent reasoning matters, but so do Job identity, state, recovery, and idempotency.
In an earlier JEV email classification article, I separated Model Judgment from Business Decision: the model could propose a score and category, while the application decided what business state to assign. The same boundary appears here in execution. Agent Execution is not the Business Job. The Agent can perform an attempt; the application must retain authority over the Job’s identity and lifecycle.
The original question was whether an Agent could analyze a corporate PowerPoint template and produce a reusable mold. A proof of concept could answer that. A service has to answer who remembers the work when execution fails or stops. That memory belongs in a durable control plane that retains the Job’s identity, state, artifacts, execution evidence, and next permitted action.
In Enterprise AI, the Agent does not have to outlive the task. The task has to outlive the Agent.