Case Study: A Feature Delivered Across Jira, Confluence, and Bitbucket — With None of Their CLIs Installed

We ran an experiment to answer a simple question: can an autonomous coding agent deliver a real feature across systems it was never explicitly told about? Not a toy in a sandbox we control, but a genuine task spanning an issue tracker, a documentation wiki, and a code host — none of whose command-line tools are installed in the environment the agent starts in.

To make it honest, we built a deliberately foreign stack. The work item lived in Jira Cloud as issue SCRUM-5, labelled and linking a Confluence page that held the real acceptance criteria. The code lived in Bitbucket — a FastAPI and React demo application. The agent's base image had none of the Jira, Confluence, or Bitbucket CLIs baked in. If the agent wanted to talk to any of these systems, it would have to work that out and provision the tools itself.

Two ClusterCode design principles made this possible. The first is that the DevBox — the disposable container each task runs in — is the agent's capability layer: when a job needs a tool the container lacks, the agent installs it on demand rather than failing. The second is project configuration by reference: a ClusterCode project carries the repository URL and its secrets, and at launch they are injected into the DevBox. Crucially, the secret values never enter the agent's reasoning context — only an opaque project identifier travels with the prompt. The credentials resolve server-side.

This is the real unlock, and it is worth stating plainly: because the DevBox is a real machine the agent fully controls — not a vendor-hosted sandbox with a fixed, curated tool list — the ceiling on what an agent can do is far higher. You bring your own CLIs, your own API tokens, and your own app connections; the agent installs and runs them with genuine machine capabilities — spawning processes, calling any API, driving any provider's command-line tool, standing up an entire language toolchain. Most hosted agents are confined to whatever surface their vendor chose to expose. Here, the orchestrator runs the work on infrastructure you own, with the tools you pick, against the systems you already use. The agent is not limited to a sandbox's menu — it gets a machine.

The prompt we gave deliberately named no tool, no provider, and no language. It said, in effect: work on Jira issue SCRUM-5 end to end in this project's repository — read it and the documentation it links, then have Claude plan it, Codex review the plan, Claude implement, Codex code-review the implementation, route findings back to Claude to fix, and open a pull request that references the issue. Work it like a small team.

Here is what the agent — Nova, our orchestrator — actually did, narrated from its execution trace. It launched a DevBox and tried to clone the repository. The first clone prompted for credentials; Nova found the injected Bitbucket token in the environment and retried through git's credential helper, explicitly noting it would do so without echoing any secret values into the transcript. The clone succeeded.

It then recognized the issue tracker was Jira, installed the jira CLI on demand, authenticated with the injected token, and read SCRUM-5 along with its linked Confluence specification — the acceptance criteria for a parse_duration helper that converts strings like 1h30m into a total number of seconds.

The multi-agent loop ran as instructed. Claude planned the implementation: where the function should live, how to parse unit segments in descending order. Codex reviewed and approved the plan, adding regex validation for unsupported units and eight additional edge cases. Claude implemented it. When the DevBox turned out to have no test runner, the agent installed pytest into a throwaway virtual environment — another on-demand capability install — and ran the suite: 25 parametrized tests, all passing.

Finally, with no Bitbucket CLI to lean on, the agent pushed its branch and opened the pull request directly through the Bitbucket REST API — a single authenticated POST that returned HTTP 201. Pull request number one, titled after the issue and closing it, appeared on Bitbucket. Total wall-clock time: about twenty-four minutes.

We want to be honest about the rough edge, because it is the most useful part. Nova did not wire the injected Bitbucket token into git on its own. It cloned fine, but at push time it hit a credential error and paused to ask the operator how to authenticate; it paused a second time needing the account email as the username for the REST call, correctly reasoning that the workspace username works for git but not for the API. Three short operator nudges in total, all on the same Bitbucket authentication seam.

That gap is not an agent deficiency — it is a platform one. ClusterCode already pre-wires git credentials at launch for GitHub repositories, so the agent never has to think about authentication there. Bitbucket simply is not covered yet. The fix is small and scoped: configure git's credential helper from the injected token at clone time for every supported provider, exactly as we already do for GitHub. With that in place, the same run would complete unattended.

Throughout the entire run, the secret-by-reference design held. The trace only ever showed the name of the token variable, never its value. A scheduled, fully autonomous version of this task would carry the same property: the credentials reach the DevBox, never the model.

What this experiment really demonstrated is three properties composing into something larger than any one of them: a capability layer that lets an agent provision whatever toolchain a job needs, project configuration that delivers repositories and secrets by reference without leaking them into context, and genuine multi-engine orchestration where Claude and Codex check each other's work. Point a project at a provider, hand the agent a high-level goal, and it assembles the rest. The provider-authentication wiring is our next iteration — and a good reminder that the interesting frontier in autonomous coding is rarely the model, and usually the plumbing around it.