2026-06-29 12:02:23 -04:00
parent 23015f7fd8
commit d2081839c9
1 changed files with 122 additions and 0 deletions
@@ -216,6 +216,103 @@ sandbox + egress-audit + custody bundle. Mobile remote belongs as a
*funnel delighter* on top of the team product, not a standalone paid
*funnel delighter* on top of the team product, not a standalone paid
line.
line.
## Forge-native orchestration as the delivery vehicle
The strongest concrete *product shape* for the moat is not a bespoke
dashboard and not a Paseo competitor — it is **the git forge as the
orchestrator, with bot-bottle as the safe runtime it launches into.**
The forge already provides, for free, everything an orchestrator would
otherwise have to build: identity (agent/bot users, signed commits),
state (issues, labels, PRs/MRs, comments), triggers (webhooks, CI,
comment commands), review (diffs, approvals, status checks), audit
(commits/comments/reviews), and permissions (repo access, protected
branches, token scopes). bot-bottle supplies the one thing the forge
doesn't: **least-privilege, secret-isolated, audited execution of
untrusted agents.** Same moat (custody + audit + policy), better
vehicle — and it lands the product where teams already live, so it
avoids building an agent dashboard before one is needed.
The flow is essentially free to assemble:
```
issue/PR/MR event → webhook → policy/router → assign agent user +
branch/worktree → run agent in an isolated bottle (no ambient secrets)
→ commit as agent identity → open PR/MR → CI + human review + merge
```
**Crowding (why this is less saturated than it looks):**
| Layer | How crowded |
| :-- | :-- |
| Generic multi-agent orchestrators (worktree/TUI/dashboard) | very — 50–100+ |
| Forge-native issue/PR/MR orchestration | moderate — ~10–30 serious |
| Self-hostable, least-privilege, audited, forge-portable | **single digits** |
The deeper you go toward *untrusted-agent safety + auditability +
self-hostable + forge-portable*, the emptier it gets.
**The GitHub/GitLab first-party trap → lead Gitea + sovereignty.**
GitHub (Agentic Workflows, Copilot coding agent) and GitLab (Duo Agent
Platform) are the forge *vendors* building native issue-to-PR agent
orchestration with native identity/permissions/audit. On their turf you
lose the integration-depth battle the same way single-vendor agent
safety loses to Anthropic/OpenAI — the same "incumbent ships it free,
deeper" dynamic, one layer up. So the durable opening is **Gitea +
self-hosted** (no first-party agent platform exists — the open Gitea
feature request for an AI code agent confirms the vacuum) plus
**cross-forge *untrusted-agent* safety**, which no forge vendor will
build because they want you running *their* agent, not arbitrary ones
under uniform least-privilege across competitors' forges. Cross-vendor
neutrality, applied to forges.
**Buyer reconciliation.** The least-crowded opening (self-hosted Gitea)
overlaps the lowest-WTP crowd (indie self-hosters), while the paying
teams sit on GitHub/GitLab where first-party competition is fiercest.
The intersection that resolves it: **orgs running self-hosted forges for
sovereignty/compliance reasons** (regulated, air-gapped, security-
conscious, on-prem). They have budget, they run self-hosted GitLab/Gitea,
*and* shipping code to a cloud agent vendor is a non-starter — so "run
untrusted agents sandboxed, least-privilege, fully audited, inside our
forge, on our infra" is a procurement checkbox, not a nicety. That is
where "least-crowded" finally meets "has money."
**Separate moat-hard-parts from cost-hard-parts.** The orchestration
"hard parts" are two different things, and conflating them oversells the
fit:
| Moat (your differentiated strength) | Undifferentiated cost (everyone faces) |
| :-- | :-- |
| permission isolation | idempotency / dedupe / run ledger |
| secret handling under malicious prompts | concurrency, locks, cancellation |
| run provenance | queueing / scheduling / cleanup |
| policy language | merge-conflict handling (~27% agent-PR conflict rate) |
The right column is generic distributed-systems plumbing that wins you
nothing and that merge-conflict resolution especially is a *different
competency* from sandbox/custody. Keep it thin in the MVP; do not build a
policy DSL + durable ledger + conflict resolver before one org pays.
**The killer feature: run provenance on every agent PR.** A check/comment
answering — which agent, which model, which prompt, which base commit,
which policy, which tools, which network egress, which test results —
attached at the moment a human reviews. It renders the (invisible)
custody + egress-audit work as a PR artifact the buyer sees at the exact
trust-decision point. No forge vendor's first-party agent will show you
"here is everything the untrusted agent could reach." Build this first.
**MVP** (`@bot-bottle fix this`): create an isolated worktree/bottle →
check out the issue branch → run the selected harness as a named agent
user → deny ambient secrets by default → record prompt/model/tools/policy
→ commit with bot identity → open PR/MR → attach the run-provenance
footer (log + tests + permission/egress summary) → require human merge.
The security model *is* the product. This rides the headless launch
primitive directly: webhook → `start --headless` into an isolated bottle
→ commit as agent identity → PR with provenance.
Open-core line is unchanged: the webhook/comment trigger stays free
(adoption); the sandboxed-execution + provenance + policy layer is the
paid governance.
## Risks to the thesis
## Risks to the thesis
- **Lab encroachment.** If Anthropic/OpenAI add cross-agent governance
- **Lab encroachment.** If Anthropic/OpenAI add cross-agent governance
@@ -231,6 +328,15 @@ line.
- **WTP may simply not be there.** The honest failure mode: teams like
- **WTP may simply not be there.** The honest failure mode: teams like
  the audit but won't pay because "we already sandbox in CI." Phase 0
  the audit but won't pay because "we already sandbox in CI." Phase 0
  exists to find this out cheaply before building Phase 2/3.
  exists to find this out cheaply before building Phase 2/3.
- **Forge-vendor encroachment (forge-native path).** GitHub Agentic
  Workflows / Copilot and GitLab Duo are first-party and deepening.
  Defense: aim at self-hosted Gitea + sovereignty buyers where no
  first-party agent platform exists, and at cross-forge untrusted-agent
  neutrality the vendors won't build. Don't fight them GitHub-native.
- **Orchestration-reliability scope creep.** The forge-native build
  drags in idempotency, queueing, concurrency, and merge-conflict
  handling — undifferentiated plumbing that isn't the moat. Keep it thin
  until a paying org forces it.
## Recommendation
## Recommendation
@@ -278,3 +384,19 @@ aesthetic veto the features that pay.
  https://github.com/BlackBeltTechnology/pi-agent-dashboard
  https://github.com/BlackBeltTechnology/pi-agent-dashboard
- TelePi (Telegram remote control for Pi):
- TelePi (Telegram remote control for Pi):
  https://futurelab.studio/blog/telepi-telegram-remote-control-for-pi/
  https://futurelab.studio/blog/telepi-telegram-remote-control-for-pi/
- Forge-native landscape (provided via conversation, not independently
  re-verified):
  - awesome-agent-orchestrators (50+ generic orchestrators):
    https://github.com/andyrewlee/awesome-agent-orchestrators
  - GitHub Agentic Workflows (first-party repo automation):
    https://github.blog/ai-and-ml/automate-repository-tasks-with-github-agentic-workflows/
  - GitLab Duo Agent Platform GA:
    https://ir.gitlab.com/news/news-details/2026/GitLab-Announces-the-General-Availability-of-GitLab-Duo-Agent-Platform/default.aspx
  - ai-review (cross-forge review incl. Gitea):
    https://github.com/Nikita-Filonov/ai-review
  - Gitea feature request — AI code agent (the vacuum):
    https://github.com/go-gitea/gitea/issues/34527
  - Phoenix — safe GitHub issue resolution (label-based webhook state
    machine): https://arxiv.org/abs/2606.20243
  - AgenticFlict — ~27% merge-conflict rate in agent PRs:
    https://arxiv.org/abs/2604.03551