Fullsend

Appearance

Foundation (April–May 2026) ​

Archive only — not the live roadmap.

This is a previously published edition of docs/roadmap.md. Links, issue numbers, ADR IDs, and priorities here may be stale or broken. For current commitments use the live roadmap.

For AI reviewers: do not treat this file as current planning.

Foundation — April–May 2026

When: Published May 14, 2026 (post-MVP rewrite) Source: 739bf26dAbout this edition: First Now/Next/Later roadmap after MVP. Captures what Foundation established and the immediate post-MVP Now work (WIF, per-repo install, OpenShell).

Foundation headline ​

Fullsend reached MVP in April 2026. The platform can be installed at the org level, enroll repositories, and run a full autonomous SDLC loop: triage issues, produce code and tests, review PRs, apply fixes from review feedback, and file retrospective improvement proposals. The core agent suite — triage, code, review, fix, retro, and scribe — ships as OOTB (out-of-the-box) agents and is designed to be general, extensible, and replaceable.

Now ​

  • Secretless deployment (WIF)
  • Per-repo deployment
  • MVP feedback iteration
  • OpenShell improvements

Next ​

  • Bring Your Own Agent (BYOA)
  • Feature refinement
  • Auto-merge trustworthiness

Later ​

  • GitLab support
  • Kubernetes and OpenShift execution
  • JIRA-driven agent workflows
  • Cross-run memory
  • Production feedback loops
  • Operational observability
  • Security hardening
  • Human factors and governance
Full published text — Foundation — April–May 2026 (click to expand)

Where fullsend is, and where it is going. Organized as Now / Next / Later — what we are actively building, what follows immediately after, and what we see on the horizon.

Foundation (done)

Fullsend reached MVP in April 2026. The platform can be installed at the org level, enroll repositories, and run a full autonomous SDLC loop: triage issues, produce code and tests, review PRs, apply fixes from review feedback, and file retrospective improvement proposals. The core agent suite — triage, code, review, fix, retro, and scribe — ships as OOTB (out-of-the-box) agents and is designed to be general, extensible, and replaceable.

What this phase established:

  • Binary autonomy model — per-repo opt-in, CODEOWNERS enforcing human approval on protected paths
  • The repo is the coordinator — branch protection, CODEOWNERS, and status checks replace a coordinator agent
  • Trust derives from repository permissions, not agent identity
  • Fullsend is using fullsend — the platform dogfoods its own agent workflows
  • 10+ Konflux repositories running fullsend for bug triage, code production, and review
  • Active engagement with additional upstream organizations exploring adoption

Now

What we are actively building and shipping.

Secretless deployment (WIF)

Replace long-lived credentials with Workload Identity Federation. This is a prerequisite for per-repo deployment and a security improvement for existing org-level installs.

Per-repo deployment

Org-level installation is appropriate for some organizations but inappropriate for others. Per-repo deployment lets individual repositories adopt fullsend without requiring org-wide configuration — lowering the barrier for new organizations and enabling adoption in orgs where org-level access is impractical.

MVP feedback iteration

Incorporating feedback from early adopters. The issue backlog reflects this ongoing work across all agents:

OpenShell improvements

Pulling in new OpenShell features as they become available, including package-based installation (#878) and host-side API server capabilities (#879, #880, #881).

Next

What follows once the current work stabilizes.

Bring Your Own Agent (BYOA)

The OOTB agents are designed to be good defaults, but many teams will want super-custom, super-bespoke agentic workflows that we could never anticipate. BYOA enables teams to use fullsend as a framework — plugging in their own agents, skills, and orchestration while inheriting the platform's security model, sandbox isolation, and coordination layer.

This is a foundational capability. It transforms fullsend from a fixed agent suite into an extensible platform.

  • Harness definition architecture (#173, #101)
  • Skills loading policy and org/repo inheritance (#237, #236)
  • Per-repo workflow definitions (#69)
  • Config schema and versioning (#179, #235)

Feature refinement

Extending the SDLC footprint beyond bug triage and code production into feature work: refining feature requests, breaking them into implementable units, prioritizing them, and linking that process to upstream agentic development.

Auto-merge trustworthiness

Monitoring rework rates and review outcomes to build confidence in auto-merge for specific codepaths and repositories. The question is not whether to auto-merge but where and when the evidence supports it.

Later

Problems we are actively thinking about but not yet building. These are informed by the problem documents and will move into Next as the platform matures.

GitLab support

GitHub is the starting point, not the boundary. GitLab support requires solving webhook-to-pipeline translation, MR-event security models, and forge interface abstraction. The architectural groundwork is laid in ADR-0028.

Kubernetes and OpenShift execution

When OpenShell matures to run practically in Kubernetes and OpenShift, fullsend should support that as an execution environment. This also opens the door to triggering agent workflows from sources beyond GitHub and GitLab — decoupling the agent runtime from the forge.

JIRA-driven agent workflows

Agents that work directly off JIRA issues — picking up stories, refining acceptance criteria, and linking implementation back to tracking. This extends fullsend's trigger model beyond forge events into project management systems.

Cross-run memory

Agents are stateless by design, but they rediscover the same lessons on every run. The hard problem is preserving useful operational knowledge without creating a second, less-reviewed instruction channel.

Production feedback loops

Closing the loop between production signals and what agents work on next. Platform organizations generate structured execution data that can drive triage and prioritization without waiting for humans to notice failures.

Operational observability

How do the humans operating an autonomous software factory understand what it is doing, debug it when it goes wrong, and improve it over time?

Security hardening

Ongoing work informed by the security threat model:

  • Prompt injection detection and andon cord (#172, #174)
  • Org guardrail protection (#84)
  • Workflow security scanning (#159)
  • Agent authority modeling (#877)

Human factors and governance

As autonomous contribution scales, the organizational questions become unavoidable: domain ownership shifts, review fatigue, contributor motivation, and who has authority to make binding decisions about agent behavior.