---
title: Business capabilities and execution engines
description: Separate business objects, capability types, and distribution packages when integrating DSH or another engine.
lastVerified: 2026-09-24
---

# 6.2 Business capabilities and execution engines

Teloa organizes business work above an execution engine. Before integrating a feature, identify its layer and who owns its state, authorization checks, and results. Start with [Three product layers](https://docs.teloa.ai/markdown/en/concepts/layers.md).

## 1. Product layers and engineering responsibilities

**AI-Native Team Studio = AI Team + Agent Studio + Agent Harness**. These are product layers, not three services or code packages.

| Product layer | Owns | Integration constraint |
| --- | --- | --- |
| AI Team | Colleagues, business areas, projects, groups, tasks, automations, approvals, and results | Preserve lasting identities, business ownership, history, and delivery criteria |
| Agent Studio | Roles, knowledge, skills, tools / MCP, and permission configuration | Declare provenance, scope, and required authorization; configuration does not elevate access |
| Agent Harness | Models, runtimes, tool gateways, sandboxes, approvals, and observability | Use official interfaces, enforce permissions, and return real execution state |

Team is the product, Agent is the unit of work, and Harness is the runtime foundation. Business, capability, and execution remain useful engineering responsibilities rather than a competing product model. See [Source architecture](https://docs.teloa.ai/markdown/en/develop/architecture.md) for system and package boundaries. An extension package distributes skills, connections, and runtime components; it is not a fourth layer.

## 2. Mapping DSH objects

The current adapter builds on DSH. This table defines conceptual boundaries; see [Native runtime capabilities](https://docs.teloa.ai/markdown/en/guides/native-capabilities.md) for version-specific availability of native panels.

| Native concept | Use in Teloa | Not equivalent to |
| --- | --- | --- |
| Plugin | Registers tools, services, interfaces, or configuration | A business skill or role |
| Bundle | Combines plugins and configuration with distribution provenance | A Teloa industry solution or business resource package |
| Agent preset | Selects model and runtime configuration | An AI colleague's lasting identity and permissions |
| Agent Team / teammate | A task team and temporary task assistants | A work group and lasting AI colleagues |
| Session / job | Conversation and execution facts | Acceptance of a business task |
| Workspace / directory | Execution location and file boundaries | A Teloa business project |

An AI colleague can select a runtime configuration while retaining its own responsibilities, memories, and business permissions. A task assistant's name is not an identity credential and cannot grant a same-named colleague's permissions. An ordinary conversation can organize a task team without automatically becoming a business task with an owner and acceptance criteria.

## 3. Track distribution, configuration, runtime, and permissions separately

Do not collapse these facts into a single “enabled” field or force every capability through a fixed sequence:

| Fact | Question to answer |
| --- | --- |
| Provenance and installation | Which publisher, package, and version supplies it? Did installation finish? |
| Saved configuration | Is it enabled globally or in a particular runtime configuration? Is a restart pending? |
| Actual runtime | Did the current host load it successfully? Are there errors? |
| Connection and credentials | Is the external service reachable, and which authorized account does it use? |
| Business permissions | Which colleague may use which operations within which business area or task? |

Omit dimensions that do not apply. Official or third-party describes the publisher; bundled or user-installed describes delivery. Neither alone determines whether a component can be disabled.

Skills and connections supplied by an extension package must retain their package ownership. The Capabilities page can project those resources, but must not treat them as separate installations or uninstall them twice. Engine plugin inventory diagnoses global and preset-scoped components; not every internal component needs to become a business capability that users manage.

Teloa's pending installation records, content hashes, request identifiers, and receipts support approval and interruption recovery. Preserve those business records when reusing the native installer. Native installation success does not replace business confirmation or authorization.

## 4. Reuse official capabilities first

Use official services for execution, cancellation, session reading, and plugin management when the engine provides them. Thin adapters map these services to Teloa tasks, owners, approvals, and deliverables without duplicating the engine's state machine.

For managed tasks, Task/Run owns business attribution. Native session, member, and background-work identifiers link execution facts. After a stop request, report stopped only when work actually ends. Disconnection or pending cancellation must not appear as completion. Successful execution also does not establish that a deliverable passed acceptance.

Keep interface responsibilities consistent: Market supports discovery, Capabilities manages available resources, Settings configures runtime parameters, and component inventory supports diagnosis. This direction does not mean every entry point has already been consolidated. Follow the [capabilities guide](https://docs.teloa.ai/markdown/en/guides/capabilities.md) for current operations.

## 5. Specify the integration method

When evaluating another product, specify whether the integration imports skills, connects MCP, adapts a distribution format, or uses an official execution interface. Importing a resource does not make its originating product a selectable Teloa engine.

Different ecosystems define packages differently. See [Codex Plugins](https://developers.openai.com/plugins/concepts/plugins), [Claude Code Plugins](https://code.claude.com/docs/en/discover-plugins), [Cursor Plugins](https://cursor.com/docs/plugins), [OpenCode Plugins](https://opencode.ai/docs/plugins/), and [Kiro Powers](https://kiro.dev/docs/powers/). These are conceptual references, not a Teloa compatibility list. Different major versions, including OpenCode versions, require separate verification.

## 6. Integration acceptance

1. Record the engine version, supported integration methods, and unsupported capabilities.
2. Define mappings between business identity, capability provenance, runtime configuration, and native execution identifiers.
3. Test installation, configuration activation, connection failure, and authorization denial separately. Errors must lead to an actionable user entry point.
4. Test cancellation of parent and child work, reconnection, and host restart without losing attribution or reporting false completion.
5. Verify one complete task using an isolated database and real host, then check states and messages in both Chinese and English.

See [Source architecture](https://docs.teloa.ai/markdown/en/develop/architecture.md) for code responsibilities and [Execution permissions](https://docs.teloa.ai/markdown/en/develop/permissions.md) for authorization checks. This page defines integration conventions, not a stable third-party Harness SDK.