Integrations

Halyard connects two kinds of external accounts: the AI providers your agents authenticate as, and the Git providers your work lives in. AI accounts are available today; Git provider linking is in progress.

AI accounts (available today)

Agents authenticate as a real provider account. You add a provider key once, then link it into each enclave that should use it.

1. Add a provider key

In Settings → AI accounts, add a key for Claude, Gemini, or OpenAI. Keys are:

• encrypted at rest and write-only — once saved, only a masked hint (the last few characters) is ever shown back;
• renamable and rotatable from the same screen.

2. Link the key to an enclave

On the Enclaves page, open an enclave’s AI keys panel and associate one of your keys per provider. From then on, sessions in that enclave can use that account.

This per-enclave association is what keeps accounts scoped: a key linked to your corporate enclave is never reachable from an open-source one. See Enclaves & security.

Note

There are two distinct things here. The enclave AI key above is a key Halyard uses for its own server-side AI features (e.g. AI-assisted task breakdown). The account an agent authenticates as on a node is an AI provider link — the CLI account logged in on that machine — chosen per session at dispatch.

Git providers (planned)

Linking GitHub, Azure DevOps, and Bitbucket — to clone repos, open pull requests, and capture incoming issues/reviews — is designed but not yet available in the app (Settings → Connections shows it as coming soon). This section documents the intended model so the design is clear; the connection UI and steps will land here when the feature ships.

Source-of-truth rule

Halyard is the canonical store for issues, tasks, requirements, PRDs, goal docs, and their history. Providers are designed as a one-way fan-out, never an authority:

• no shadow tables mirroring external records;
• Halyard-side edits never write back to the provider;
• no external system changes a Halyard work item’s content, status, or links.

This is deliberate. Two-way issue-tracker sync tends to grow into a maintenance burden out of proportion to its value — drift erodes trust and conflict rules accrue special cases. Halyard chooses “Halyard is the truth.”

The inbox: capturing external signal (planned)

External signal will land on the inbox — a capture lane, not your backlog. The ingestion engine will populate inbox items from GitHub assignments, Azure DevOps mentions, Bitbucket review requests, and manual prompts, each recording its source and a reference back to the original ticket.

An inbox item is never itself a canonical work item. When you triage one, you promote it into a Halyard issue — the inbox item isn’t deleted, it’s marked promoted and stamped with the new issue, so the inbox can show ”✓ promoted to ENG-42”.

Link-out, not deep integration

Work items will reference external systems only through opaque, display-only URL fields — a task’s PR URL, an issue’s external links. The substance of the work always lives in Halyard.