Integrations

Preserve meaning when information crosses tools

An integration can bring a useful observation into a workflow, but its value depends on preserving source identity, scope and permissions. A tool event such as “command finished” is not automatically evidence that the intended engineering outcome was achieved.

Questions an integration must answer

• What information does it read or produce?

• Which task, workspace or work unit does that information concern?

• What source state and producer can be identified?

• Which permissions allow the read or action?

• How are retries, errors and incomplete observations represented?

Code context and work evidence have different roles

Explorer relationships can support the explanation of a proposed change. A test runner can provide an observed result. A plan can record the intended approach. Combining them should preserve those distinctions instead of treating every tool response as an interchangeable proof of completion.

Availability

Supported public integrations, provider setup and connection requirements have not been announced. These docs do not promise a named third-party connector or instruct you to supply credentials. Join the waitlist for product availability updates.