Suppose you assign a customer research task to AI: compare several proposals, explain their applicable conditions, and deliver a recommendation supported by evidence. Once the model starts, the product faces three questions: Who is responsible for the recommendation? What methods does that employee use? What actually happened during this execution?
Teloa addresses them through three product responsibilities. AI Team organizes work and collaboration. Agent Studio defines how employees work. Agent Harness handles execution, currently through DeepSeek Harness (DSH).
The reason for separating them becomes clearer when something changes. A new customer requirement, a better research method, or a runtime upgrade should not force users to rebuild the entire piece of work. Each layer retains what should continue, and specific tasks and runs connect them.
AI Team: who is responsible for the recommendation?
Start with the working relationships. The user has a goal, a research employee handles the comparison, and a content employee may use the findings to prepare client-facing material. A project provides a shared direction, tasks carry delivery requirements, and a group lets participants discuss findings and limitations.
These relationships remain useful after the model stops. The user needs to find the original employee, identify the artifact being used, and request a revision. If those meanings are assembled on demand from chat messages and tool logs, one “done” reply can be mistaken for execution ending, a report being delivered, and the user accepting it.
AI Team therefore maintains the working relationships among employees, tasks, collaboration, projects, and artifacts. It establishes which responsibility a recommendation belongs to and where the next participant continues. A content employee receiving a research file cannot automatically be considered to have understood and applied every limitation in it.
Changes specific to this layer concern the work arrangement. Adding a comparison requirement or handing the next step to another employee calls for maintaining the task and handoff. It does not require copying the research method, and it must not rewrite previously accepted content.
Agent Studio: how does this employee work?
Knowing that a task belongs to a research employee is not enough. The same model can produce a fluent overview or a comparison that meets strict sourcing requirements. The difference depends on the material, methods, and tools available to it, and the decisions it must return to the owner.
Agent Studio organizes these maintainable capability definitions. In Teloa, they include responsibilities, knowledge, skills, tools, and permissions. Responsibilities define the extent of the employee's work; knowledge supplies factual material; skills retain checking procedures; tools enable actions; and permissions constrain what may be accessed and changed.
Continue with the customer research. An updated service description calls for maintaining the knowledge source. Repeated failures to check expiry dates call for revising a research skill. Comparing only two suppliers this time belongs in the task requirements. Putting all three changes into one prompt can turn temporary client conditions into lasting role rules and scatter shared methods across individual tasks.
Maintaining capability definitions separately lets improvements remain useful within an appropriate scope. The role retains lasting standards, while the task supplies the current material and goal. Applicable components are then prepared for that execution. Naming a tool in a definition does not establish that it is available or that permission to use it has been granted.
Agent Studio here is a product responsibility, not a requirement for a separate page with that name. Employees, knowledge, skills, and connections remain maintained through their respective entry points. What matters is having the right place for a change: revising a research procedure should improve the method without requiring a new employee or a rewrite of every customer task.
Harness: how does this execution happen?
Prepared capabilities still need to run. Reading material, calling models and tools, waiting for child work, handling approvals, stopping, and returning results each involve an execution process. Teloa uses DSH's native conversations, child work, execution events, and approvals for those processes.
For this research, Teloa links the task to an actual run. DSH organizes model and tool execution, and confirmed execution facts inform the displayed progress. A stop request must reach the corresponding execution; tool decisions use native approval. Changing an interface state alone cannot establish that the model and its child work have stopped.
Changes specific to the Harness layer concern execution mechanisms: model calls, tool processes, or recovery contracts may evolve. Teloa must check how the corresponding events still relate to the original task, rather than make users rebuild projects and roles after a runtime upgrade.
Execution cannot make every product judgment. A DSH end result establishes the corresponding terminal state of that process. Artifact persistence, compliance with the comparison requirements, and user acceptance each need their own basis. “Run ended” and “Waiting for review” can both be true.
Connecting the layers into one piece of work
When a role task starts, it fixes the corresponding task and role versions, prepares material and methods, and links a native run. This connects a specific responsibility, the capability definition it uses, and its actual execution.
For example, when later work adopts a revised research skill with an expiry check, the change must enter the corresponding preparation. Earlier reports retain the methods used at the time, independently of the new definition.
A gap in the report can also be traced through these relationships. An unstated requirement calls for clarifying the task; a missing check calls for revising the skill; material a tool failed to obtain calls for examining the execution. Clear maintenance responsibilities make it easier to choose a remedy that fits the problem.
The next change is the test
The three layers divide product responsibilities. They do not correspond one to one with code packages, databases, or interface menus, and they do not establish full compatibility between runtimes. When something changes, they help identify the main work involved and what needs to continue.
| What changes | Main maintenance responsibility | What needs to continue |
|---|---|---|
| The client adds a comparison requirement | AI Team: adjust the task and corresponding handoff | Role standards and research methods that still apply |
| The research method adds an expiry check | Agent Studio: revise the skill and establish which version is adopted | The history of how earlier reports used the previous method |
| The runtime is upgraded | Harness and Teloa integration: check calls, events, and recovery contracts | Original tasks, roles, and accessible artifacts |
Teloa owns the integration that preserves these relationships as runtime contracts change. The next research task is where the value of the layers becomes apparent: users can bring new requirements to an existing employee and method while retaining a clear account of the work already completed.