Tether

Waiting on another team and hoping they deliver? Tether turns every ask into a promise with real odds, right inside Jira. Just tether it.

Comment

Inspiration

Every launch we have been part of ran on promises from other teams. Legal will review the terms by Friday. Security will sign off next week. Design will have the assets ready. Those promises lived in comments, chat threads and a weekly status meeting whose only job was to find out which of them were still true. The date on a Jira link was a guess, the owning team never really agreed to it, and when it slipped nobody downstream heard until launch day.

The problem is well documented. In Atlassian's State of Teams 2025 research with 12,000 knowledge workers, leaders and teams said they waste a quarter of their time just searching for answers. In Jira, the views that show dependencies across teams sit in Plans, which needs Premium or Enterprise, and a suggestion for cross-project dependencies calls the native setup so cumbersome that it is usually not used.

The motto is build with context, ship with confidence. We wanted the confidence part to be literal: a number on every promise, earned from how the owning team actually works.

What it does

Tether turns a request from one team to another into a negotiated commitment with odds attached.

  • Ask. From any work item, Ask another team picks the team, the date and the number of pieces of work. Before you send it, Tether replays the owning team's real pace 2,000 times and shows how likely your date is, why, and the trade-offs: a later date, a split in scope, or the team making room for a few weeks.
  • Negotiate. The ask lands on the owning team's desk with the same forecast and the arithmetic behind it. They commit, counter with a date or a split, or decline with a reason. Only people on that team can answer for it.
  • Commit. When both sides agree, Tether creates the work in the owning team's own space, links it to the asking item, and posts the record on both sides. The owning team needs no setup.
  • Keep. Tether listens to every issue change and replans each night. Promises depend on promises, so when one slips the whole chain is re-forecast and everyone downstream hears about it the same day. A what-if shows who a slip would move before anyone agrees to it.
  • Deliver and learn. Tether shows the pull requests and deployments the Teamwork Graph links to the owning team's work. Every delivered or missed promise scores the forecast that came before it, so each team builds a reliability record and its 85% comes to mean 85%.

You meet it where you already work: a timing-tower board across teams, a desk per team, a panel and a sidebar glance on every work item, a Confluence macro for the launch plan, two Rovo agents, and the same tools over Atlassian's MCP server.

How we built it

Tether is entirely native Forge and eligible for Runs on Atlassian. There are no outside servers and no data leaves Atlassian.

  • Jira. A global page with the board and team desks, a project page desk inside each space, an issue panel, an issue context glance and an issue action for Ask another team.
  • Confluence. A readiness macro with its own configuration.
  • Runtime. Custom UI in React with Atlassian Design System tokens, Forge SQL with 14 migrations for commitments, asks, events, policies and forecast snapshots, KVS caches, an async queue for replans, team sync and the sample launch, issue event triggers, a nightly scheduled replan, and Realtime so every open screen updates when something changes.
  • Rovo. Two agents, Tether for asking teams and Tether Desk for owning teams, with three skills and twelve actions. Agent actions go through the same permission checks as the app, and changes like a team's capacity ask the person to confirm first.
  • MCP. The same twelve actions are served through Atlassian's MCP server for any MCP client, such as Cursor.
  • Teamwork Graph. Which Atlassian team owns which space, who is on it, which goals a work item supports, and the deployments and pull requests linked to the work.

The forecast. For a team with daily completions c₁ … cₙ over its recent window and a share s of its time given to asks, each simulated day draws a past day at random and thins it.

$$k_t \sim \text{Binomial}(c_{U_t},\ s), \qquad U_t \sim \text{Uniform}\lbrace 1,\dots,n \rbrace$$

A trial finishes on the first working day T where the items finished so far reach q + m, with q items ahead in the queue and m items in the ask.

$$\sum_{t \le T} k_t \ \ge\ q + m$$

Over N = 2,000 seeded trials, the odds of a date d are

$$\hat{P}(T \le d) = \frac{1}{N}\sum_{i=1}^{N} \mathbf{1}[T_i \le d]$$

Dependencies gate each trial on the upstream team's finish plus a lag, so a slip propagates through the graph. Honesty is scored with the Brier score over every closed promise,

$$\text{BS} = \frac{1}{M}\sum_{j=1}^{M} (p_j - o_j)^2$$

where pⱼ was the forecast at commitment and oⱼ is 1 if it was delivered on time.

Challenges we ran into

  • Making odds honest rather than optimistic. Teams without history fall back to the capacity they declare and say so, stale history uses its own window, and every forecast shows a receipt: pace × share = ask items a week, against the work ahead.
  • Permissions on open sites. Many Jira sites let everyone edit every space, so "can edit" alone would let anyone answer for any team. Tether uses team membership from the Teamwork Graph and the teams you say you are on.
  • Keeping agents truthful. After an agent changes a policy, the action returns the new odds for every affected promise, so the agent reports real numbers rather than ones from earlier in the chat.
  • Forge limits. Team sync moved to the queue so no request ever waits on it, and Realtime messages carry only ids, with every screen refetching through permission-checked calls.

Accomplishments that we're proud of

  • A full loop between four people on four teams, live in Jira: ask, counter, split, renegotiate, accept, and work created and linked in the right spaces.
  • Slips that propagate. When Security moves its review, the Metering API that waits on it drops from 36% to 0%, and the launch that waits on that moves too.
  • One set of tools that behaves the same in the app, in Rovo and over MCP.

What we learned

The hard part of cross-team work is not tracking. It is agreement. A probability turns "can you do this by Friday" into a conversation both sides can have honestly, and a record of how often each team kept its word is worth more than any status field.

What's next for Tether

Automation actions so rules can raise and answer asks, organisation-wide default policies, bulk triage on a team's desk, and a free listing on the Atlassian Marketplace for business teams. Longer term, the reliability record becomes the system of record for how teams depend on each other.

Built With

Share this project:

Updates

Submission history