Glossary
This glossary defines the product terms used across the docs, APIs, and agents. Linked terms open the page that covers them.
Terms
| Term | Meaning |
|---|---|
| Workspace | A separate environment with its own members, teams, integrations, taxonomy, and data. |
| Team | A group inside a workspace used for planning, standups, boards, recaps, and reporting. |
| Member | A person with access to the workspace. Members can also belong to teams. |
| Role | The access level a member has in a workspace or team. |
| Permission | A rule that controls what someone can view, configure, or change. |
| Initiative | Planned work that needs a brief, owner, and roadmap visibility. |
| Bug | A defect or incident that needs review, ownership, and repair. |
| Idea | A feature request or product suggestion that has not become planned work. |
| Ongoing work | Recurring tasks without a clean end date. |
| Todo | Simple unfinished personal work. |
| Completed task | Finished work shown in the Journal, recaps, standups, reports, and measurement. |
| Issue | Work synced from an issue tracker such as Jira, Linear, GitHub, or GitLab. |
| Pull request | Code review work from a version control provider. GitLab merge requests appear in the same delivery views. |
| Document | Supporting context that can stay attached to initiatives, bugs, todos, agents, or team knowledge. |
| Spec | The initiative, bug, or todo a person, coding tool, or agent starts from. |
| Writer Mode | A writing flow that turns rough initiative, bug, or todo notes into a structured brief. |
| Status | The current state of work, such as planned, in progress, blocked, completed, or cancelled. |
| Roadmap | The planning view for initiatives and ongoing work that should stay visible beyond today. |
| Backlog | Intake for work that is not scheduled yet. |
| Triage | Review for potential bugs or feature requests before they are accepted or declined. |
| Board | A Kanban view for planned, in-progress, done, and blocked work. |
| Ownership | Responsibility for moving work forward or reviewing it. |
| Blocker | A dependency, decision, missing input, or external issue that stops progress. |
| Recap | A daily view of completed, planned, and blocked work. |
| Journal | The chronological view of completed tasks and captured work. |
| Standup | A team update built from completed work, planned work, and blockers. |
| Insights | Workspace and team charts for delivery, planning, pull requests, taxonomy, and agents. |
| Taxonomy | Workspace terms that connect work to goals, companies, products, skills, coding tools, and agents. |
| Taxonomy type | A supported taxonomy category, such as goal, company, product, skill, coding tool, or agent. |
| Integration | A connected app that brings in work, code, meetings, messages, or automation. |
| MCP | A Model Context Protocol connection that lets AI assistants read and act on workspace context. |
| CLI | The one command-line tool for terminal work, setup, and local agent commands. |
| REST API | The HTTP API for reading and changing workspace data from services, scripts, and CI. |
| API key | A workspace-scoped credential for trusted backend services, CI, and internal automation. |
| OAuth app | A custom app that uses Log in with One Horizon or Connect One Horizon with user-approved access. |
| Webhook | An outbound event sent to a service when workspace activity happens. |
| Agent | Software that receives work and reports progress back to the original initiative, bug, or todo. |
| Agent session | One queued unit of agent work. |
| Claim | The lease that lets one eligible agent execute an agent session. |
| Coding agent | The plain-language name for an agent harness. Used wherever "agent harness" would add unnecessary jargon. |
| Agent harness | The software that turns a model into an agent by managing context, tools, permissions, approvals, sessions, and the agent loop. Codex, Claude Code, Cursor Agent, and ACP agents you install yourself are all agent harnesses. |
| Model | The reasoning model an agent harness sends work to. A harness can support several models, and the model is chosen separately from the harness. |
| Worker | The One Horizon host process that claims agent sessions and runs a harness. A worker is not the harness it hosts. |
| Worker configuration | What a worker is allowed and asked to do: capabilities, permissions, concurrency, worktree behavior, hooks, and workflow defaults. Separate from which harness the worker runs. |
| Execution environment | Where commands run and files change: a local machine, a worktree, a sandbox, a container, or a cloud environment. An execution environment is not automatically a sandbox. |
| Custom harness | An ACP-compatible coding agent you build, install, and run yourself instead of using a built-in one. |
| Runtime | Reserved for genuine execution substrate: a language runtime, the live state of a worker process, or a runtime failure. It does not mean the coding agent you picked. |
| Workflow | A saved execution plan that coordinates agent-driven delegation, human gates, branches, and workflow-produced documents against an initiative, bug, or task. |
Harness, model, worker, environment
When a coding agent works on a task, the harness, model, worker, and execution environment are independent. You can run the same harness against a different model, on a different worker, in a different environment, and it is still the same harness.
Some older pages say "runtime" where they mean the harness.