Agent-native collaboration and the next software forge

Assessment

CoFactory’s strongest opportunity is a shared place where a community defines useful work, agents propose implementations, people try alternatives, and accountable maintainers decide what advances. This is a product recommendation, not an established market consensus. Public evidence supports demand for less review burden, better context, controlled agent authority, dependable infrastructure, and easier operations. It supports the broader claim that people want to participate in choosing software less directly.

The competitive field is already crowded. GitHub has integrated multiple coding agents, GitLab has released lifecycle orchestration, Cursor has launched a Git forge, and Entire has expanded from checkpoints into search and Git infrastructure. Replacing repository hosting simply to add an agent button would enter an active market with considerable switching costs. CoFactory should initially work with repositories and agents people already use. GitHub Agent HQ, GitLab announcement, Cursor documentation, Entire search.

The distinguishing promise should be concrete: a group can turn a shared need into a chosen, evidence-backed implementation without every participant learning a pull-request workflow. It should be possible to judge a useful result without confusing preference with security approval, a passing test report with independent verification, or a selected candidate with a production deployment. The current shared workspace establishes that collaboration record. Managed execution and deployment remain subsequent work.

Evidence and scope

This assessment focuses on small software communities, open-source maintainers, and teams bringing their own coding agents. It combines maintainer accounts, public discussion, product documentation, and empirical research available on 11 September 2026. Vendor descriptions establish advertised capabilities and release status; they do not establish customer satisfaction or independently verified performance. Forum comments establish particular requests and objections, not the prevalence of those views.

The discussion sample is purposive: threads about agent forges, contribution overload, context capture, and integrated hosting. It overrepresents English-speaking developers willing to discuss tooling publicly. Small-community participants, nontechnical users, and dissatisfied developers are not interchangeable populations. No market size, willingness-to-pay estimate, or percentage of developers demanding a new forge can be inferred from this sample. The 2025 survey below is a historical baseline, not a measurement of September 2026 adoption.

The original Origin scratchpad supplies a useful design direction: portable records, explicit claims, and continuity across tools. Its cryptographic ambitions should be separated from product outcomes. A valid signature demonstrates control of a key for particular bytes; it does not independently establish a unique human, truthful authorship, correct software, or complete disclosure of an agent’s work. A hosted collaboration service also should not describe itself as peer-to-peer merely because its exported artifacts are portable. Origin remains the local release protocol within CoFactory; Cursor’s unrelated product uses the same name.

Requests appearing in public discussion

These are paraphrases of identifiable contributions. They are useful design inputs, not a vote count or a representative survey.

The Cursor thread is especially instructive because participants disagree about what would justify moving. Its product developer described the initial release as functional parity with further agent integrations to come. That is a launch-time statement; current documentation should govern present capability claims. The enduring product question is whether the new system reduces actual work rather than just relocating familiar screens. Origin launch discussion.

Maintainer attention and contribution quality

Admission before generation

Mitchell Hashimoto’s Vouch makes trust an explicit prerequisite for selected project interactions. Its configurable vouch and exclusion lists have a portable file representation and GitHub integrations. The repository describes the system as experimental and in use by Ghostty, drawing on Pi’s approach. It is evidence of maintainers building admission controls, not proof that an invitation requirement is appropriate for every community. Vouch repository.

GitHub has responded as well. Its June 2026 announcement describes persistent limits on open pull requests from users without write access, a trusted-contributor bypass list, and AI-created requests counting toward the limit; drafts are excluded. Named maintainers from Homebrew, AutoGPT, and OpenClaw describe the value of controlling volume. The same announcement marks additional controls as upcoming, so it should not be used to claim those later features are already available. GitHub contribution limits.

For CoFactory, a task should become available to agents only after a maintainer approves its brief and acceptance checks. Membership approval controls who can submit; time-limited claims prevent duplicate effort; submission limits bound review load. These controls should be visible and understandable. A contributor should know whether work is wanted before spending time or tokens producing it. The platform should help a newcomer earn trust through small useful contributions, rather than substitute a permanent popularity ranking for judgment.

More useful findings can also overwhelm reviewers

Daniel Stenberg’s April 2026 account complicates a simple narrative about low-quality AI work. After curl ended its bounty and later returned to HackerOne, he reported that low-quality submissions were no longer the central problem: report volume and quality had both increased. He still expected greater maintainer overload. This is one project’s account, accompanied by an explicitly unscientific comparison with others; it does not establish a universal trend or isolate the effect of the policy changes. High-Quality Chaos.

The implication is broader than spam filtering. Even accurate findings create triage, validation, patching, regression testing, communication, and release work. CoFactory should measure the cost to resolve a need, including review and maintenance, instead of celebrating candidate count. An agent that identifies a bug should ideally supply a reproduction and a bounded repair proposal. A contributor who follows through on a difficult review may be more valuable than one who submits many plausible first drafts.

Experience still matters

A study accepted to the MSR 2026 Mining Challenge examined 22,953 pull requests from 1,719 developers in the AIDev dataset. Its lower-experience group received 4.52 times as many review comments and had a reported 31% lower acceptance rate than the higher-experience group. These are observational associations within a selected dataset, with experience estimated from lifetime commits divided by GitHub account age; they do not prove that novice status or AI use caused a particular review outcome. Asdaque and colleagues.

CoFactory should make room for different contributions. A domain expert may describe a problem well, an agent may implement it, a tester may expose a failure, and a maintainer may integrate the result. Collapsing those roles into a single author score would lose useful information. Credit should record what each participant actually did. Selection criteria should make it possible to reject an implementation while preserving the value of the underlying problem report and the person who supplied it.

Context, coordination, and agent authority

Context should be recoverable and selectively shared

Entire’s checkpoint design associates code changes with prompts, transcripts, attribution, and token information. The March article, updated in August, explains that checkpoint metadata can live separately from code and that identifiers survive common history rewrites. On 3 September it announced search across code and context. Its search performance figures come from its own small benchmark of engineering-history questions and should not be generalized to every repository. Checkpoint design, Search release.

The disagreement in the Entire discussion is about the right unit of memory. Some participants value retaining the path from intent to implementation; others see full sessions as costly or distracting and want simple conversation retrieval. CoFactory should support a short durable decision record, optional links to deeper context, and private working history by default. Making every raw transcript public is unnecessary for evaluating a candidate and may expose unrelated material. Entire discussion.

A useful handoff answers five questions: what is being attempted, what is already known, what changed, what evidence exists, and what should happen next. It should point to exact versions and preserve unresolved uncertainty. A summary is a navigation aid, not a substitute for the underlying evidence. If a later agent cannot distinguish an approved requirement from a discarded suggestion, adding more context may make its work worse.

A durable queue is different from a chat transcript

Beads implements a dependency-aware issue graph and persistent agent memory, using Dolt. Its documented workflow includes discovering unblocked work and atomically claiming a task. This is a concrete example of structured coordination becoming a product in its own right. It is not a general proof that every team needs Dolt or that identifier design eliminates semantic conflicts between changes. Beads repository.

Jujutsu provides another useful distinction: teams can change their local version-control workflow while remaining compatible with Git repositories. Its documentation describes Git-backed workspaces and native support for multiple working copies, alongside compatibility limitations. An agent-friendly collaboration layer does not need to invent a repository format to improve coordination. CoFactory should preserve the source revision supplied by any compatible workflow and avoid making a particular editor mandatory. Jujutsu compatibility.

Task claims are only the beginning. A mature queue needs dependencies, cancellation, renewal, budget limits, retry semantics, and clear ownership when an agent disappears. Work should return to the queue after a lease expires; the next agent should see what happened. Two valid candidate branches can still conflict at integration time. CoFactory’s current claims coordinate one task at a time; they do not automatically resolve code conflicts or provide a full multi-repository scheduler.

Authority must have a scope and an end

MCP’s authorization guidance separates tokens intended for an MCP service from downstream credentials and explicitly rejects token passthrough. GitHub Actions OIDC offers short-lived access to cloud providers without storing a corresponding long-lived cloud secret in GitHub. These are existing mechanisms for reducing credential handling while preserving distinct permission boundaries. They do not make repository, runtime, data, and billing authority identical. MCP authorization guidance, GitHub OIDC.

The recommended CoFactory model is delegation: an owner grants a particular agent a small set of project actions for a limited time. Reading public work should require no login. Claiming, submitting, selecting a release, changing access, and deploying are different powers. This release implements custom project tokens for the first group of write actions; it does not implement OAuth discovery or claim full compliance with the MCP OAuth authorization profile. Clients must support a configured Bearer header.

The agent should receive a role, not the owner’s identity backup. Revocation must stop further writes and release outstanding claims. Browser agents should act through a visible session control and have their contributions labeled accordingly. A platform cannot reliably infer whether every member-generated submission involved AI, so labels should describe the authenticated channel and disclosed assistance rather than promise perfect authorship detection.

What the competitive landscape already covers

This is a capability comparison, not a quality ranking. Availability, pricing, plan restrictions, and performance can change quickly. No competitor was subjected to a common hands-on benchmark here. An omitted feature is not evidence that a provider lacks it. The strategic conclusion is that CoFactory should prove a specific collaboration outcome before taking on the cost of replacing mature Git hosting, deployment infrastructure, or an enterprise policy system.

GitHub’s weakness for this proposed audience is an interaction-model mismatch: reviewing changes to source is central, while a nontechnical group may need to articulate needs, try several outcomes, explain preferences, and fund or maintain the chosen tool. That is an analytical judgment, not a claim that GitHub lacks issues, projects, discussions, previews, or extensibility. The opportunity is to make the group’s decision process coherent and accessible across those components.

Integrated setup and the separate-keys question

Yes, parts of the setup problem have been solved. Replit documents authentication that its agent provisions without a separate provider signup or copied OAuth keys. Lovable documents a managed application stack with custom domains, a backend, storage, authentication, integrations, and optional Git synchronization. These products demonstrate that builders do not inherently need to assemble several dashboards before making a useful application. Replit authentication, Lovable hosting options.

The remaining distinction is between a unified experience and unrestricted access. Source control governs changes; a runtime executes them; a database holds application state; a domain routes traffic; external services have their own accounts and costs. A platform can provision these on a user’s behalf and present one workspace, while internally keeping permissions separate. Existing OIDC support shows how some deployment credentials can be issued on demand. GitHub OIDC.

Portability is more than downloading a repository. Lovable’s own migration documentation notes that an application may depend on Supabase-specific authentication, storage, realtime, and edge services; moving to plain PostgreSQL is not an equivalent complete migration. The operational burden returns to the operator when leaving a managed environment. Code export, data export, identity migration, secrets reconfiguration, and an exercised restore procedure should be assessed separately. Lovable ownership and deployment.

A current Lovable community question asks specifically for branch-level backend isolation so experimental code cannot mutate real tenant data. That post establishes a concrete user requirement and confusion about a particular setup. It does not establish that every Lovable configuration lacks isolation. The provider documentation, rather than a comment thread, should decide current support. For CoFactory, the lesson is to make the scope of a preview explicit before users trust it. Staging discussion.

The recommended future CoFactory deployment experience is one project with a managed default: repository or imported source, preview runtime, isolated test database, secrets boundary, domain, logs, and rollback. Additional providers should be connectable when necessary. The interface should explain what a release will change and its expected cost. A user should approve a concrete release plan, not assemble infrastructure by copying opaque keys into chat. This remains a proposed product phase; the current shared workspace links external previews and records selections.

Collective taste as a product hypothesis

The strongest broad evidence for a collaboration opportunity is indirect. Stack Overflow’s 2025 survey reports that 17% of respondents to its agent-impact question agreed that agents improved team collaboration, versus approximately 70% reporting time savings on specific tasks. The impact question had 12,823 responses. In a different question, 66% reported frustration with almost-correct solutions. These are self-reported experiences from 2025 and different question populations, not a controlled productivity comparison or a current forecast. 2025 survey.

Collective taste could help where a specification is incomplete: a community knows which experience feels clearer, faster, more useful, or more appropriate only after trying alternatives. It could also fail through low participation, popularity bias, inconsistent criteria, coordinated voting, or a preference for attractive demos that break under realistic use. Public sources reviewed here do not establish that developers broadly want majority voting to replace maintainers. The claim should remain testable.

The recommended comparison unit is two fixed candidates for one approved task. Ask a reviewer what they tried, which candidate helped, and why; permit a tie. Preserve the candidate versions and the task criteria. Randomizing the initial pair order can reduce a simple presentation bias, but it does not make the comparison blinded or statistically representative. External preview links can change, so a credible later evaluation system must bind a build and its environment to a fixed revision.

Human preference, agent critique, automated checks, security review, and maintainer selection should remain distinguishable evidence. Combining them into one score would suggest an equivalence that does not exist. A hundred agents can cheaply produce a hundred opinions; that should not count as a hundred independent people. A signature identifies a key, not a unique participant. Community membership and accountable decisions are necessary starting controls, while stronger resistance to duplicate identities remains future work.

StrongDM’s account offers a different route: agents converge against scenarios, with human effort moved toward specifying and validating behavior. Its techniques describe evaluating externally observable outcomes rather than traditional code inspection. That approach is useful inspiration for acceptance checks; it does not establish that a popular preview can replace scenario testing or that all communities can safely dispense with expert review. StrongDM techniques.

CoFactory should therefore treat taste as a choice among eligible outcomes. First establish the task and required checks; then collect experience with alternatives; then have a maintainer explain the selection and remaining tradeoffs. A later release gate verifies deployment readiness. The public history should preserve why a less popular candidate was chosen when reliability, accessibility, or maintenance cost justified it. The goal is a better shared decision, not a more elaborate scoreboard.

Product priorities and current boundaries

The current service stores public collaboration records centrally. It is not a decentralized Git forge, a hosted coding-agent service, or a runtime for submitted applications. It does not execute arbitrary candidate code, verify contributor test results, merge repositories, or deploy the selected candidate. Agent tokens are project-scoped and expire; browser signing identities remain local. These boundaries should remain visible in the product until the corresponding capabilities actually exist.

The next infrastructure step should be a narrow, reproducible preview contract. A runner receives an approved task, source revision, build instructions and isolated test data; it returns a build identity, a preview, check results and expiration. The service should be able to revoke that environment and relate a later production release to the selected build. Start with one supported application shape, because pretending to deploy arbitrary software would obscure both reliability and cost.

Do not start with a universal reputation token, automatic majority-rule releases, forced repository migration, or an unrestricted agent marketplace. Those expand governance and trust assumptions before the core workflow has evidence. Also avoid presenting agent-generated review prose as independent validation. The useful early product is a small, dependable collaboration loop that a maintainer can understand, supervise, and leave with its records intact.

Validation plan

Recruit five willing communities or maintainer-led teams for a bounded pilot; this is a proposed experiment, not completed outreach. Each should bring a real recurring software need and retain its existing repository and coding tools. Begin with a small task whose acceptance criteria can be demonstrated within a session. Have participants use the shared brief, agent claim, candidate submission, comparison, and selection flow at least twice, so novelty alone is less likely to explain engagement.

Measure review minutes per accepted outcome, elapsed time from approved task to usable candidate, abandoned claims, duplicate work, the share of candidates with reproducible evidence, and the number of tasks reopened after selection. Record whether participants return voluntarily. Count failures and setup assistance, not just completed demonstrations. Candidate volume, token consumption, and generated lines are operational measurements, not success outcomes by themselves.

For collective taste, compare two workflows on similarly scoped tasks: maintainer review alone and maintainer review with structured participant comparisons. Track whether the added feedback changes the decision, discovers a previously missed usability problem, or only adds time. Record the number and background of reviewers. A small pilot can reveal workflow failures and promising cases; it cannot establish a general causal effect or a universal scoring model.

Ask nontechnical participants to describe the chosen candidate and its limitations without reading a diff. Ask maintainers whether the task queue reduced unwanted work. Ask agent operators whether they could resume after interruption using the record alone. Ask project owners to export the history and identify what is missing from a complete migration. These exercises test the proposed advantages directly rather than asking whether people like the phrase “agent-native GitHub.”

A reasonable continuation criterion is that several independent teams repeat the loop, report lower review burden or better choices, and can identify why the record is useful after the session ends. If teams primarily value coordination, deepen task handoffs and repository adapters. If they value comparing outcomes, invest in isolated previews and evaluation. If they only want integrated deployment, reconsider positioning against established application builders instead of treating every demand as one market.

Sources

1. GitHub / Mario Rodriguez. Pick your agent: Use Claude and Codex on Agent HQ. 4 February 2026. Product launch; capability and preview status at announcement.
2. GitLab. General availability of GitLab Duo Agent Platform. 15 January 2026. Official capability announcement.
3. Cursor. Origin documentation. Undated, checked 11 September 2026. Current early-beta capabilities and access limits.
4. Entire / Rizèl Scarlett. The Entire CLI: How It Works and Where It’s Headed. 25 March 2026; updated 28 August 2026. Checkpoint design and context storage.
5. Entire / Evis Drenova. Introducing Agentic Search for Code and Context. 3 September 2026. Search release; benchmark is vendor-run.
6. Entire / Marvin. Push during Upstream Downtimes with Entire-Native Branches. 9 September 2026. Git infrastructure update.
7. GitHub / Camilla Moraes and Ashley Wolf. How pull request limits are cutting down the noise. 18 June 2026. Shipped controls, maintainer testimony, separately labeled roadmap.
8. Mitchell Hashimoto and contributors. Vouch. Living repository, checked 11 September 2026. Explicit community trust model; experimental status.
9. Daniel Stenberg. High-Quality Chaos. 22 April 2026. First-person curl maintainer account.
10. Syed Ammar Asdaque and colleagues. Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding. 27 February 2026; accepted to MSR 2026 Mining Challenge. Observational AIDev study.
11. Hacker News participants. Cursor launches Origin, GitHub alternative. August 2026 discussion, checked 11 September 2026. Qualitative comments and developer replies.
12. Hacker News participants. Ex-GitHub CEO launches a new developer platform for AI agents. February 2026 discussion, checked 11 September 2026. Competing preferences about context and portability.
13. Beginning-Fruit-1397 and r/Python participants. How to deal with slop PR’s as a maintainer?. June 2026 discussion. Self-reported contribution-quality concerns.
14. sleepysiding22 and r/selfhosted participants. I don’t think I can maintain PR’s anymore at Postiz. March 2026 discussion. Self-reported maintainer workload.
15. Still-Corner-360 and r/lovable participants. Is there really no way to have an isolated staging database with Lovable Cloud + GitHub?. September 2026 discussion, retrieved 11 September 2026; page dates are relative. User requirement, not authoritative product-support documentation.
16. Beads contributors. Beads repository. Living documentation, checked 11 September 2026. Structured agent memory and atomic task claims.
17. Jujutsu contributors. Git compatibility. Living documentation, checked 11 September 2026. Compatible workflows and stated limitations.
18. StrongDM / Justin McCarthy. Software Factories and the Agentic Moment. 6 February 2026. First-party description of a software-factory experiment.
19. StrongDM. Techniques. Undated, checked 11 September 2026. Behavioral validation and scenario-based practice.
20. Stack Overflow. 2025 Developer Survey: AI. 2025. Self-selected survey; question-specific populations and historical baseline.
21. Replit. Auth. Undated, checked 11 September 2026. Agent-provisioned authentication options.
22. Lovable. Deployment, hosting, and ownership options. Undated, checked 11 September 2026. Integrated hosting and migration boundaries.
23. GitHub. OpenID Connect. Undated, checked 11 September 2026. Short-lived workload access to cloud providers.
24. Model Context Protocol contributors. Authorization, specification 2025-06-18. Versioned protocol guidance. Token audience and downstream credential separation; cited as a specific version, not the latest specification.
25. Origin scratchpad, “A Peer-to-Peer System for Verifiable Collaboration.” User-supplied pasted-text.txt, attributed within the document to Y. Malahov. Private attachment supplied as a design proposal; authorship and factual claims were not independently authenticated. Not reproduced in this report.