Preflight
Request origin
Observed need in a real workflow
Problem or unmet outcome
Long-running agents may need to repeatedly rediscover repository architecture, dependencies, relevant files, and implementation relationships after a restart or handoff. This can increase exploration/tool calls and make architectural assumptions harder to verify.
The desired outcome is for a LoopX-managed agent to optionally retrieve current, repository-grounded context without making LoopX responsible for maintaining the repository intelligence itself.
Use case
A LoopX goal is working on a large repository across multiple sessions. After a restart or handoff, the agent needs to understand which components are relevant to the current objective, what depends on them, and where the relevant behavior is implemented.
An optional repository-intelligence provider such as Rune could supply that context, while LoopX continues to own goals, progress, gates, quotas, handoffs, and continuation.
Proposed outcome
Explore an optional, provider-neutral interface through which LoopX capabilities can request repository context and evidence. The interface should allow an agent to retrieve relevant files, relationships, architectural context, and source-backed evidence, while keeping LoopX's control-plane responsibilities separate.
A useful first step would be a small experiment on an existing public LoopX issue rather than committing to a full integration.
One candidate for this experiment is Rune, an open-source Software Intelligence Runtime: https://github.com/thecolourfoundation/rune
LoopX area
Control plane (goals, todos, quota, scheduler, registry, runtime)
Alternatives considered
Direct repository search, grep/ripgrep, and asking the underlying coding agent to rediscover repository context each session. These remain useful and should continue to work. The proposed integration is intended as an optional additional context source rather than a replacement.
Scope and non-goals
In scope:
Evaluate Rune as an optional repository-context provider.
Retrieve repository-grounded context and source evidence.
Test the effect on a real LoopX workflow.
Compare exploration/tool usage and correctness with and without the provider.
Out of scope:
Replacing LoopX's control plane.
Replacing the underlying coding agents.
Making Rune a required dependency.
Changing LoopX's existing goal, quota, or handoff model.
Contribution
Preflight
Request origin
Observed need in a real workflow
Problem or unmet outcome
Long-running agents may need to repeatedly rediscover repository architecture, dependencies, relevant files, and implementation relationships after a restart or handoff. This can increase exploration/tool calls and make architectural assumptions harder to verify.
The desired outcome is for a LoopX-managed agent to optionally retrieve current, repository-grounded context without making LoopX responsible for maintaining the repository intelligence itself.
Use case
A LoopX goal is working on a large repository across multiple sessions. After a restart or handoff, the agent needs to understand which components are relevant to the current objective, what depends on them, and where the relevant behavior is implemented.
An optional repository-intelligence provider such as Rune could supply that context, while LoopX continues to own goals, progress, gates, quotas, handoffs, and continuation.
Proposed outcome
Explore an optional, provider-neutral interface through which LoopX capabilities can request repository context and evidence. The interface should allow an agent to retrieve relevant files, relationships, architectural context, and source-backed evidence, while keeping LoopX's control-plane responsibilities separate.
A useful first step would be a small experiment on an existing public LoopX issue rather than committing to a full integration.
One candidate for this experiment is Rune, an open-source Software Intelligence Runtime: https://github.com/thecolourfoundation/rune
LoopX area
Control plane (goals, todos, quota, scheduler, registry, runtime)
Alternatives considered
Direct repository search, grep/ripgrep, and asking the underlying coding agent to rediscover repository context each session. These remain useful and should continue to work. The proposed integration is intended as an optional additional context source rather than a replacement.
Scope and non-goals
In scope:
Evaluate Rune as an optional repository-context provider.
Retrieve repository-grounded context and source evidence.
Test the effect on a real LoopX workflow.
Compare exploration/tool usage and correctness with and without the provider.
Out of scope:
Replacing LoopX's control plane.
Replacing the underlying coding agents.
Making Rune a required dependency.
Changing LoopX's existing goal, quota, or handoff model.
Contribution