AI work is easily reduced to a request and a reply. Real delivery does not end at those boundaries: missing material can arrive later, a draft needs revision, and an accepted version may receive new requirements.
The product therefore needs three kinds of object. A task retains responsibility for delivery, a run records specific execution, and an artifact retains evolving content. They often appear together but have different lifecycles.
Teloa separates them so work can change without rewriting decisions already made. A run can end while a task remains undelivered. A task can close while its artifact receives a later version. Versions retain content history; tasks retain responsibility for each delivery.
From quotations to a usable comparison table
Consider a hypothetical supplier comparison. The request is to compare prices, lead times, and support scope using the quotations provided, identify items without evidence, and deliver a comparison table.
The goal brings several capabilities into one delivery. The research role supplies lasting evidence standards, an adopted comparison skill supplies the procedure, and quotations and service descriptions supply facts. This task specifies which suppliers to compare and which conditions to list separately. Preparing a role task fixes the actual role version, skills, materials, and task requirements together for execution.
Each contributes something different. Quotations alone may produce three summaries. A comparison method calls for checks of consistent pricing units and support definitions. Delivery requirements give unsupported items a place to appear, rather than leaving the user to find omissions in fluent prose. The system organizes these inputs; research judgment still has to work from the material.
The first round may lack a quotation, the second receive it, and the third adjust the wording. The task continues the same goal while runs retain each round's conditions. The user checks whether the comparison table answers the original question, and identified differences become requirements for the next round. Linking task, run, and artifact supports gradual completion without restating the assignment whenever more material arrives.
A task name helps users find it; an explicit goal helps them judge it. If the table omits one supplier or presents uncertain conditions as facts, the issue can be checked against the original requirement rather than the fluency of the writing alone.
When a change arrives determines how work continues
Adding “List after-sales response times separately” during research can enter a suitable active run or a further run under the original task. The system needs to record where it actually entered. Editing the goal text cannot rewrite inputs that have already been sent.
After closure, the situation is different. The deliverable was accepted under the requirements at the time, and new feedback asks for another delivery. Overwriting the old content would make the original acceptance refer to something the reviewer has never seen. Continually reopening the old task can also obscure the distinction between the two assignments.
In the current general-purpose work path, a deliverable from a completed task can be revised as follows:
- Save feedback and explicitly send it back to AI.
- After approval, the system creates a separate follow-up task and run.
- The follow-up task produces a new version of the same deliverable.
The original task still points to the old version, and the follow-up task to the new one.
Users need not save another file with a similar name, and the system need not pretend that the earlier acceptance always applied to the latest content. The deliverable improves while each responsibility leaves its own record.
Feedback should refer to definite content
“Make the after-sales section more specific” depends on the original version and passage. Feedback left only in a new conversation may lead the executor to use a different historical version, or rewrite already accepted prices and lead times along the way.
Teloa's revision request fixes the deliverable, version, feedback, and selected passage. The delivered version keeps the same deliverable identity and records which follow-up work produced it. It can be obtained from the task and compared through the original deliverable.
This revision can be understood as a specific agreement: start from v1, change only the support section, retain the price comparison, and return the next version of the same artifact. The user expresses the intention; the system fixes the basis and scope needed for execution. That connection keeps a local edit from silently becoming a complete rewrite.
It also explains why “last save wins” is insufficient. If a person has produced v2 while AI worked from v1, writing AI's result directly would lose the person's work. Retaining an unapplied candidate adds a reconciliation step but protects both contributions. Artifact identity provides continuity; version conditions determine whether a write can proceed.
The task-artifact relationship matters more here than file naming. The task establishes responsibility for this revision; the artifact records how content evolves. A follow-up task after completion lets each responsibility point accurately to its own delivery.
Changed wording still needs the original problem checked
Another model pass may improve the prose or remove an important condition. In tasks with a review step, Teloa separates draft correction from verification before delivery.
Review addresses the draft to be delivered in this round. For a local revision, it checks the revised text of the selected passage; the rest of the original deliverable is outside that review. Correction retains the problem, evidence, and affected content, and verification then checks whether the original problem was resolved.
Evidence quotations are restored from fixed source excerpts, rather than replaced by similar sentences copied out again by the model. Finding the original passage is followed by judging whether it actually supports the change.
This constrains structure and evidence relationships without replacing judgment about arbitrary business facts. Whether a quotation remains valid or two conditions are comparable still depends on material and professional judgment. System delivery review and the user's acceptance remain different decisions.
An accepted version needs to remain valid as a record
An accepted version needs to remain explainable. Content reviewed last week must not silently change when a new version appears today. Preview and download also need to refer to the same definite content.
Separating responsibility from content increases relationship maintenance inside the product while reducing users' need to create extra files, identify versions, and explain earlier acceptance. It also gives later revision a place: new requirements correspond to new work while the content develops as the same artifact.
This is completion designed for iteration. It records acceptance of a responsibility under the conditions at that time and retains an accurate starting point for later change.