The intake promise.

Primary surfaces

• changelog official changelog https://developers.openai.com/codex/changelog
  watch: releases / new features / improvements / bug fixes / breaking changes
• docs official docs https://developers.openai.com/codex/
  watch: cli / app / ide extension / web / workflows / subagents / sandboxing / memories / commands / agents md / mcp / plugins / skills / authentication / approvals / security / governance / automation
• repo github repo https://github.com/openai/codex
  watch: releases / tags / commits / pull requests / issues / docs / examples / security
• npm package registry https://www.npmjs.com/package/@openai/codex
  watch: package version / publication date / install surface

Accepts as evidence

• official changelog
• official docs
• github release
• tagged release
• maintainer commit
• merged pr
• official blog or developer post
• package registry release
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

pricing or usage change

observe

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy
• accessibility

High-signal patterns

goal / long-horizon / subagent / memory / workflow / sandbox / approval / permission / command / hook / MCP / plugin / skill / AGENTS.md / local environment / browser / computer use / automation / non-interactive / SDK / cost / usage

Operator questions

• Does this change how an operator should run, trust, or govern Codex?
• Does this affect long-horizon autonomous software work?
• Does this affect verification, replay, resume, permissions, memory, or receipts?
• Does this change whether teams should wrap, test, adapt, or ignore Codex capability?
• Does this make serious agent work easier to start, inspect, or control without hiding authority?

Discovery state

last verified: 2026-05-06 / manual web / high confidence

• Which GitHub releases, tags, and npm package versions should be treated as canonical when they disagree with the official Codex changelog?
• Which provider-native long-horizon features should be detected through local probes rather than relying on release notes?

Primary surfaces

• changelog official changelog https://code.claude.com/docs/en/changelog
  watch: releases / new features / improvements / bug fixes / breaking changes
• whats-new official digest https://code.claude.com/docs/en/whats-new
  watch: notable features / examples / operator guidance / weekly rollups
• docs official docs https://code.claude.com/docs/en/overview
  watch: memory / hooks / slash commands / plugins / skills / subagents / permissions / settings / sandboxing / mcp / sdk / headless / telemetry / enterprise
• package package registry https://www.npmjs.com/package/@anthropic-ai/claude-code
  watch: package version / publication date / install surface

Accepts as evidence

• official changelog
• official docs
• official whats new
• package registry release
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

pricing or usage change

observe

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy
• accessibility

High-signal patterns

recap / resume / rewind / plan / subagent / task / hook / permission / managed setting / plugin / skill / slash command / MCP / SDK / headless / telemetry / prompt caching / usage / model picker / enterprise

Operator questions

• Does this change how an operator should govern Claude Code sessions?
• Does this affect agent lifecycle, resume behavior, planning, permissions, or hooks?
• Does this change whether teams should defer to Claude Code-native capability?
• Does this create a new adapter, eval, receipt, or capability-profile need for teams running it in production?
• Does this make serious agent work easier to start, inspect, or control without hiding authority?

Discovery state

last verified: 2026-05-06 / manual web / high confidence

• Which GitHub source backing the published changelog should be captured directly in addition to the rendered official docs?
• Which Claude Code behaviors should be probed locally because the changelog is too granular to imply operator impact by itself?

Primary surfaces

• repo github repo https://github.com/google-gemini/gemini-cli
  watch: releases / tags / commits / pull requests / issues / discussions / docs / roadmap / security
• releases github releases https://github.com/google-gemini/gemini-cli/releases
  watch: stable / preview / nightly / breaking changes / security
• docs official docs https://google-gemini.github.io/gemini-cli/docs/
  watch: changelog / installation / authentication / configuration / commands / context files / checkpointing / tools / mcp / extensions / headless / ide / sandboxing / trusted folders / enterprise / telemetry
• npm package registry https://www.npmjs.com/package/@google/gemini-cli
  watch: package version / publication date / dist tags

Accepts as evidence

• official docs
• github release
• tagged release
• maintainer commit
• merged pr
• security advisory
• package registry release
• official google post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

pricing or usage change

observe

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy
• accessibility

High-signal patterns

checkpoint / resume / context file / GEMINI.md / tool call / shell / web fetch / search grounding / MCP / extension / sandbox / trusted folder / permission / IDE / GitHub Action / output format / stream-json / authentication / enterprise / telemetry / preview channel / security

Operator questions

• Does this change how an operator should trust Gemini CLI in a repo?
• Does this affect checkpointing, context files, sandboxing, tools, auth, or output contracts?
• Does this change adapter, receipt, eval, or run-contract assumptions for teams running it in production?
• Does the release-channel cadence change how operators should test stable versus preview behavior?
• Does this make serious agent work easier to start, inspect, or control without hiding authority?

Discovery state

last verified: 2026-05-06 / manual web / high confidence

• Should nightly and preview releases be harvested into findings or only used for adapter-probe canaries?
• Which security advisories should be treated as direct signals even when they do not change public docs?

Primary surfaces

• homepage https://antigravity.google/product/antigravity-cli
• releases github release https://github.com/google-antigravity/antigravity-cli/releases
  watch: releases / changelog / breaking changes / security
• changelog official changelog https://github.com/google-antigravity/antigravity-cli/blob/main/CHANGELOG.md
  watch: approvals / permissions / sandbox / subagents / mcp / plugins / breaking changes
• docs official docs https://antigravity.google/docs
  watch: cli using / approvals / permissions / sandbox / configuration / migration
• transition maintainer authored post https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/
  watch: lifecycle / deprecation / migration / tier access

Accepts as evidence

• official docs
• github release
• official changelog
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• marketing claim without doc or code

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

governance change

test

lifecycle change

adapt

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• security
• ecosystem
• philosophy
• lifecycle

Research lenses

• governance
• capability
• coordination control plane
• market succession
• closed source verifiability

High-signal patterns

approval / Always Approve / permission rule / regex / sandbox / proceed-in-sandbox / --sandbox / --dangerously-skip-permissions / subagent / always proceeds / auto approve / project permissions / dangerous paths / migration / deprecation

Operator questions

• Does a subagent's "always proceeds" auto-approval remove the human gate the parent agent was subject to?
• What does the sandbox actually isolate, and which commands does proceed-in-sandbox auto-run without asking?
• Antigravity is closed source -- how does an operator verify a governance claim they cannot read the code for?
• What is the real migration cost and behavior change moving from consumer Gemini CLI to Antigravity CLI (agy)?
• Which permission scope wins when project and global configs disagree, and can that be exploited?

Discovery state

last verified: 2026-07-01 / manual web / medium confidence

• The code is closed; governance claims rest on docs/changelog, not readable enforcement. What is independently verifiable via local probe?
• Is github.com/google-antigravity/antigravity-cli the canonical ship channel, or is antigravity.google the primary and the repo a mirror for releases/changelog?
• What license, if any, governs the distributed binaries?

Primary surfaces

• homepage https://x.ai/cli
• repo github repo https://github.com/xai-org/grok-build
  watch: commits / source rev / license / sandbox / permissions / hooks / skills / plugins / acp / worktrees
• changelog official changelog https://x.ai/build/changelog
  watch: version / permissions / sandbox / hooks / acp / headless / breaking changes / security
• docs official docs https://docs.x.ai/build/overview
  watch: install / headless / acp / skills / plugins / hooks / mcp / permissions / enterprise
• install-script install channel https://x.ai/cli/install.sh
  watch: resolved version / platform matrix / integrity verification
• open-source-announcement maintainer authored post https://x.ai/news/grok-build-open-source
  watch: license / scope / sync from monorepo

Related surfaces

watched

The public GitHub tree is a periodic sync from the SpaceXAI monorepo, not the development home. grok.com chat, Grok the model, Grok Bot, and this publication's Lane C use of the grok CLI are different objects. Omnigent can drive Grok Build over ACP; that is a fact about the pair, not about Grok Build's own tool policy.

• grok-build public mirror https://github.com/xai-org/grok-build

Accepts as evidence

• official changelog
• official docs
• tagged raw file
• git commit
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• marketing claim without doc or code
• grok com chat as harness
• grok model as harness
• unsynced main as the product
• omnigent acp wrap as grok gate

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

governance change

test

channel divergence

observe

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy

Research lenses

• governance
• capability
• distribution channel
• closed source verifiability

High-signal patterns

SOURCE_REV / Synced from monorepo / sandbox / permission / auto mode / hook / ACP / grok agent stdio / skill / plugin / worktree / headless / install.sh / GROK_CONFIG

Operator questions

• The public tree is a periodic sync from a private monorepo and GitHub has zero tags: which channel is an operator actually running, SOURCE_REV, the changelog version, or whatever the install script fetched today?
• Does a permission, sandbox, or hook rule read at a public SHA bind in the binary the install script just put on PATH?
• Native ACP is `grok agent stdio`. When Omnigent or another wrapper drives that socket, whose tool policy refuses?
• How far behind the changelog is the last public sync, and does a gap in public git prove anything about what shipped?
• Is grok.com chat, Grok Bot, or the grok-4.6 API being described as if it were this CLI?

Discovery state

last verified: 2026-08-21 / manual web / medium confidence

• Will xAI ever cut GitHub tags or Releases, or is the changelog plus install script the permanent ship channel?
• How often does SOURCE_REV move relative to a changelog version, and can an operator join them without a vendor digest?
• What license, if any, covers the distributed binary as distinct from the Apache-2.0 source tree?

Primary surfaces

• homepage https://cursor.com
• changelog official changelog https://cursor.com/changelog
  watch: editor / cli / cloud agents / origin / permissions / sandbox / subagents / goals / breaking changes
• cli-docs official docs https://cursor.com/docs/cli/overview
  watch: install / modes / headless / sandbox / sudo / cloud handoff / sessions
• install-script install channel https://cursor.com/install
  watch: resolved version / binary name / platform matrix
• docs official docs https://cursor.com/docs
  watch: cloud agent / origin / plugins / permissions / enterprise

Related surfaces

watched

github.com/cursor/cursor is a bug-tracker README. It is not the editor and not the agent. Do not harvest it as source. The changelog mixes editor, CLI, cloud agents, and Origin code hosting; a finding must name which surface it is about. Omnigent can route work onto Cursor; that is a fact about the pair, not about Cursor's own permission system.

• cursor-github-tracker issue tracker not source https://github.com/cursor/cursor

Accepts as evidence

• official changelog
• official docs
• package registry release
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• marketing claim without doc or code
• github com cursor cursor as source
• source diff of cursor github
• cloud agent changelog as cli claim
• origin hosting as permission model
• omnigent wrap as cursor gate

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

governance change

test

changelog entry

observe

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy

Research lenses

• governance
• capability
• distribution channel
• closed source verifiability

High-signal patterns

changelog / agent / cursor-agent / cloud agent / Origin / /goal / subagent / sandbox / sudo / plan mode / headless / permissions

Operator questions

• github.com/cursor/cursor is a bug tracker: did this finding treat it as source?
• Which surface moved, the editor, the `agent` CLI, cloud agents, or Origin hosting, and does the changelog actually say that?
• Can an operator pin a CLI version string or a download digest, or is the dated changelog the entire channel?
• What does `/sandbox` actually isolate, and does sudo prompting mean the model never sees the password, or only that the docs say so?
• When Omnigent routes work onto Cursor, whose permission system refuses?

Discovery state

last verified: 2026-08-21 / manual web / medium confidence

• Is there a versioned CLI release channel with a pinable digest, or only `curl https://cursor.com/install | bash` plus a website changelog?
• Do editor, CLI, and cloud agents share one permission model, or three that the changelog does not separate?
• Does Origin hosting change where an agent writes, and is that described as a control or as a product feature?

Primary surfaces

• changelog official changelog https://github.com/github/copilot-cli/blob/main/changelog.md
  watch: sandbox / permissions / allow all / enterprise policy / worktree / mcp / plugins / breaking changes / security
• releases github release https://github.com/github/copilot-cli/releases
  watch: releases / prerelease flag / changelog / breaking changes
• npm package registry https://www.npmjs.com/package/@github/copilot
  watch: dist tags / package version / publication date / latest vs prerelease
• docs official docs https://docs.github.com/copilot/concepts/agents/about-copilot-cli
  watch: approval / sandbox / trusted directories / allow all tools / acp / mcp / hooks / skills / enterprise
• repo github repo https://github.com/github/copilot-cli
  watch: license / install sh / changelog / readme

Related surfaces

watched

This source is the Copilot CLI (`copilot`, npm `@github/copilot`). VS Code Copilot, Copilot Chat, the Copilot cloud coding agent, and the older `gh copilot` extension are different products. github/copilot-cli is license, docs, changelog, and installer -- not the agent source. Omnigent's Copilot path is `gh auth login`; that is wrapper auth.

• copilot-cli changelog and releases not agent source https://github.com/github/copilot-cli

Accepts as evidence

• official changelog
• github release
• official docs
• package registry release
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• marketing claim without doc or code
• vscode copilot as cli
• copilot cloud agent as cli
• gh copilot extension as cli
• source diff of copilot cli repo
• omnigent gh auth as copilot gate

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

governance change

test

prerelease

observe

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy

Research lenses

• governance
• capability
• distribution channel
• closed source verifiability

High-signal patterns

sandbox / allow-all / allow-auto-only / --allow-all-tools / trusted director / worktree / enterprise / ACP / MCP / plugin / hook / skill / prerelease

Operator questions

• npm latest and GitHub's non-prerelease tag can lag the prerelease dist-tag: which channel did the operator actually install?
• Does a sandbox or allow-all sentence in changelog.md bind in the binary, or only on the page?
• Is this the Copilot CLI, VS Code Copilot, the cloud coding agent, or the older `gh copilot` extension?
• Enterprise allow-auto-only and sandbox proxy policy: who can turn them off, and does the CLI honor org policy when the operator is local?
• Docs describe Copilot CLI as an ACP server. Is that a shippable surface, and whose permissions apply when a wrapper drives it?
• Omnigent authenticates Copilot with `gh auth login`. Is that Copilot's gate, or the wrapper's?

Discovery state

last verified: 2026-08-21 / manual web / high confidence

• Does github/copilot-cli ever grow agent source, or is the changelog-plus-binary floor permanent?
• How often does npm `latest` lag GitHub prereleases, and is `prerelease` a channel an operator should run?
• Can org-level MCP and sandbox policies that docs say the CLI cannot honor be confirmed by a local probe?

Primary surfaces

• repo github repo https://github.com/NousResearch/hermes-agent
  watch: releases / tags / commits / pull requests / issues / docs / examples / security
• releases github releases https://github.com/NousResearch/hermes-agent/releases
  watch: release notes / breaking changes / migration notes / security
• docs official docs https://hermes-agent.nousresearch.com/docs
  watch: installation / configuration / tools / toolsets / memory / skills / mcp / messaging / cron / security / terminal backends / architecture / context files / llms txt

Accepts as evidence

• official docs
• github release
• tagged release
• maintainer commit
• merged pr
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

pricing or usage change

observe

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy
• accessibility

High-signal patterns

memory / skill / self-improvement / subagent / delegate / toolset / terminal backend / sandbox / container / SSH / Modal / Daytona / cron / messaging gateway / Telegram / Discord / Slack / MCP / context file / SOUL.md / llms.txt / trajectory / RL

Operator questions

• Does this change how an operator should think about self-improving agents?
• Does this affect long-horizon work, memory, skills, subagents, runtime portability, or messaging gateways?
• Does this change whether teams should wrap Hermes as an agent engine, compare it, or adopt an adapter assumption?
• Does this expose a governance, permission, receipt, or replay gap for teams running it in production?
• Does this make serious agent work easier to start, inspect, or control without hiding authority?

Discovery state

last verified: 2026-05-06 / manual web / high confidence

• Which docs domain should be considered canonical if GitHub README links and deployed docs diverge?
• Which social or Discord announcements are maintainer-authored enough to include, and how should they be cited?

Primary surfaces

• site official site https://pi.dev/
  watch: positioning / installation / modes / providers / design principles / package ecosystem
• docs official docs https://pi.dev/docs/latest
  watch: quickstart / usage / sessions / context files / system prompt files / compaction / skills / extensions / prompt templates / themes / packages / rpc / sdk / providers / settings
• repo github repo https://github.com/earendil-works/pi
  watch: releases / tags / commits / pull requests / issues / packages coding agent / docs / examples
• npm package registry https://www.npmjs.com/package/@earendil-works/pi-coding-agent
  watch: package version / publication date / dist tags

  Corrected 2026-07-27. This contract previously watched @mariozechner/pi-coding-agent, which has been frozen at 0.73.1 since 2026-05-07 while the live package moved to the @earendil-works scope. Watching the abandoned name meant this source read as static for eleven weeks and missed the protobufjs fix. Anyone still installing the old scope is many minors behind.

Accepts as evidence

• official docs
• official site
• github release
• tagged release
• maintainer commit
• merged pr
• package registry release
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

pricing or usage change

observe

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy
• accessibility

High-signal patterns

extension / skill / package / prompt template / theme / session tree / branch / share / export / AGENTS.md / SYSTEM.md / compaction / dynamic context / RPC / SDK / json mode / provider / login / permission / sandbox / MCP / subagent / plan mode

Operator questions

• Does this change how an operator can adapt the harness to their workflow?
• Does this affect session portability, context shaping, extension design, package distribution, RPC, or SDK embedding?
• Does Pi intentionally refusing a built-in feature force operators to supply it themselves at the extension or workflow layer?
• Does this change whether teams should wrap Pi as an agent adapter or borrow an extension-contract idea?
• Does this make serious agent work easier to start, inspect, or control without hiding authority?

Discovery state

last verified: 2026-05-12 / manual web / high confidence

Canonical repo migrated from badlogic/pi-mono to earendil-works/pi. pi.dev explicitly links to earendil-works/pi as the source. Both repos show identical release v0.74.0 (2026-05-07), confirming the migration is complete. Updated 2026-05-12.

• Which package-registry or package-index surface should be watched for Pi extension ecosystem movement?

Primary surfaces

• repo github repo https://github.com/openclaw/openclaw
  watch: releases / tags / commits / pull requests / issues / docs / examples / security
• docs official docs https://docs.openclaw.ai/
  watch: getting started / gateway / installation / configuration / channels / plugins / skills / permissions / memory / remote access / security / mobile or desktop surfaces
• getting-started official docs https://docs.openclaw.ai/start/getting-started
  watch: onboarding / setup steps / first run / user workflow

Accepts as evidence

• official docs
• github release
• tagged release
• maintainer commit
• merged pr
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• seo clone or mirror

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

accessibility change

study

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy
• accessibility

Research lenses

• accessibility
• distribution surface
• everyday use
• gateway
• authority visibility

High-signal patterns

onboarding / setup / gateway / visual surface / desktop / mobile / channel / notification / remote access / everyday user / natural language workflow / permission / approval / visibility / handoff / plugin / skill / daemon / background agent / long-running task / memory

Operator questions

• Does this make agentic work more approachable to ordinary developers or everyday users?
• Does this reduce setup, terminal fluency, or coordination burden?
• Does it simplify the surface while preserving visible authority and control?
• Does this demonstrate a more humane surface over rigorous internals that teams could adopt?
• Does this suggest a new distribution surface beyond terminal-only agent work?

Discovery state

last verified: 2026-05-07 / manual web / medium confidence

• Which OpenClaw release surface should be treated as canonical if docs and GitHub move at different speeds?
• Which user-facing gateway surfaces are official product posture rather than experimental examples?
• Which security and authority boundaries are visible enough for everyday users to understand?

Primary surfaces

• site official site https://paperclip.ing/
  watch: positioning / onboarding / governance / company model / pricing / demos
• docs official docs https://docs.paperclip.ing/
  watch: setup / goals / agents / teams / governance / budgets / accountability / approvals / integrations / security
• repo github repo https://github.com/paperclipai/paperclip
  watch: releases / tags / commits / pull requests / issues / docs / examples / security

Accepts as evidence

• official docs
• official site
• github release
• tagged release
• maintainer commit
• merged pr
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

governance change

study

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy
• accessibility

Research lenses

• coordination control plane
• economic governance
• accountability
• multi agent operations
• operating state legibility

High-signal patterns

company / org chart / goal / budget / role / manager / employee / approval / governance / accountability / cost / task queue / progress / audit / session / dashboard / multi-agent / agent team

Operator questions

• Does this make multi-agent labor more legible as operating state?
• Does this expose goals, budgets, roles, approvals, and accountability in a way a human can govern?
• Does this produce real control over agent work or only a company-themed dashboard?
• Does this change how a control plane should model run contracts, allocation, or budgets for agent work?
• Does this make coordination easier without hiding who approved what and why?

Discovery state

last verified: 2026-05-07 / manual web / medium confidence

• Which source is canonical for product changes if the public site, docs, and GitHub repository diverge?
• How much of the company/control-plane metaphor is backed by durable operating state versus UI framing?
• Which governance and budget primitives are enforceable rather than descriptive?

Primary surfaces

• site official site https://www.agent-zero.ai/
  watch: positioning / installation / ui / features / pricing / deployment
• docs official docs https://www.agent-zero.ai/p/docs/
  watch: installation / configuration / tools / code execution / browser / memory / subagents / custom tools / docker / security / remote access
• repo github repo https://github.com/agent0ai/agent-zero
  watch: releases / tags / commits / pull requests / issues / docs / examples / security

Accepts as evidence

• official docs
• official site
• github release
• tagged release
• maintainer commit
• merged pr
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

runtime change

test

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy
• accessibility

Research lenses

• workcell autonomy
• computer use
• runtime isolation
• tool creation
• visible autonomy

High-signal patterns

Linux / terminal / file system / browser / code execution / Docker / container / tool creation / plugin / custom tool / subagent / memory / task / project / remote access / UI / safety / sandbox / persistence / cleanup

Operator questions

• What does full computer access let the agent do that a narrow tool loop cannot?
• How is the environment isolated, inspected, persisted, reset, or cleaned up?
• What state is visible to the human while the agent acts?
• What happens when the agent creates tools or subagents during a long run?
• Does this change how operators should model containers, workcells, or full machines?

Discovery state

last verified: 2026-05-07 / manual web / high confidence

• Which release or docs surface best describes the current runtime isolation model?
• Which parts of Agent Zero's tool creation are safe to compare against an operator's own tool and receipt boundaries?
• Which behaviors should operators test locally versus only study as product posture?

Primary surfaces

• site official site https://openhands.dev/
  watch: positioning / cloud / enterprise / integrations / pricing / deployment
• docs official docs https://docs.openhands.dev/
  watch: installation / sdk / cli / gui / cloud / enterprise / integrations / sandboxing / security / evaluation / configuration / runtime
• repo github repo https://github.com/OpenHands/OpenHands
  watch: releases / tags / commits / pull requests / issues / docs / examples / security
• releases github releases https://github.com/OpenHands/OpenHands/releases
  watch: release notes / breaking changes / migration notes / security

Accepts as evidence

• official docs
• official site
• github release
• tagged release
• maintainer commit
• merged pr
• security advisory
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

enterprise change

study

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy
• accessibility

Research lenses

• productized agent platform
• sandboxed development
• cli gui cloud surface
• enterprise governance
• evaluation

High-signal patterns

SDK / CLI / GUI / cloud / enterprise / self-hosting / sandbox / runtime / browser / evaluation / benchmark / security / RBAC / permission / collaboration / Slack / Jira / Linear / GitHub / extension / integration / multi-user

Operator questions

• What happens when an agent harness becomes a full software-development platform?
• Which surfaces are SDK, CLI, GUI, cloud, enterprise, or integration-specific?
• How does OpenHands package sandboxing, permissions, collaboration, and evaluation for real teams?
• Which parts should teams wrap, which parts should they learn from, and which parts should they refuse to adopt wholesale?
• Does this make agentic software work easier to adopt without hiding evidence or authority?

Discovery state

last verified: 2026-05-07 / manual web / high confidence

• Which OpenHands surfaces should be treated as one product versus separate SDK, CLI, cloud, and enterprise sources?
• Which evaluation and sandboxing claims can be probed locally?
• Which integrations change operator behavior enough to become signals?

Primary surfaces

• repo github repo https://github.com/hunvreus/heypi
  watch: tags / commits / pull requests / releases / docs / examples / security
• docs official docs https://heypi.dev/docs/
  watch: getting started / concepts / adapters / approvals / audit / sandboxing / secrets / memory / skills / jobs / admin / cli / security
• landing official docs https://heypi.dev/
  watch: positioning / feature list / differentiation

Accepts as evidence

• official docs
• tagged release
• github release
• maintainer commit
• merged pr
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• marketing claim without doc or code

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

governance change

test

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy
• accessibility

Research lenses

• governance
• accessibility
• capability
• coordination control plane
• productized agent platform

High-signal patterns

approval / named approver / audit trail / SQLite / sandbox / just-bash / Docker / Gondolin / secret / memory scope / channel scope / skill / job / cron / heartbeat / admin panel / adapter / Slack / Discord / Telegram / webhook / Pi extension / durability / replay

Operator questions

• Does an approval actually block the tool call, or only surface a notification after the fact?
• Is the audit trail complete enough to reconstruct who approved what, and is it tamper-evident?
• What does a sandbox runtime (just-bash, Docker, Gondolin) actually isolate, and what leaks across it?
• How are secrets handed to a tool without passing through chat, and where do they rest?
• In a multiplayer channel, whose authority binds -- the requester's, the approver's, or the agent's config?
• Does heypi inherit Pi's "no governance in core" posture, or does it genuinely close that gap?
• What durability does heypi NOT provide (it disclaims crash-replay), and what does an operator have to own themselves?

Discovery state

last verified: 2026-06-24 / manual web / medium confidence

• heypi publishes git tags but no GitHub "releases"; is the tag the canonical ship signal, or is npm publish the real channel?
• Which governance surfaces (approvals, audit, sandbox, secrets) are on by default vs opt-in, and which bind at runtime vs surface only?
• Which version line is "stable" once 0.2.0 leaves beta, and what is the support/upgrade contract?
• What exactly does the Gondolin sandbox runtime provide relative to just-bash and Docker?

Primary surfaces

• repo github repo https://github.com/deepseek-ai/deepseek-harness
  watch: releases / tags / commits / pull requests / breaking changes / security / default branch master
• releases official release notes https://github.com/deepseek-ai/deepseek-harness/releases
  watch: prerelease flag / first stable tag / new features / breaking changes / plugin api changes / deprecations
• npm package registry https://www.npmjs.com/package/@deepseek-ai/dsh
  watch: dist tags / latest points at prerelease / package version / publish cadence
• docs official docs https://github.com/deepseek-ai/deepseek-harness/tree/master/docs
  watch: architecture / agent lifecycle / capability seams / config catalog / api gateway / plugin contract / sandboxes / permissions / user guide / i18n divergence
• advisories security advisories https://github.com/deepseek-ai/deepseek-harness/security/advisories
  watch: published advisories / severity / affected ranges
• discussions official forum https://github.com/deepseek-ai/deepseek-harness/discussions
  watch: maintainer answers / bug reports / breaking change notices / roadmap statements
• plugin-topic ecosystem index https://github.com/topics/dsh-plugin
  watch: third party plugins / plugin permissions / supply chain
• landing official docs https://deepseek.com/harness/en/
  watch: positioning / feature list / preview status

Related surfaces

watched

Harness is built on Cordis, a third-party composability framework, so the plugin boundary this harness sells is defined in someone else's repo. A change to Cordis can change what a dsh plugin may do without any commit landing in deepseek-harness. Attribute accordingly: a finding about the plugin contract must say which repo the behaviour comes from.

• deepseek-harness primary https://github.com/deepseek-ai/deepseek-harness
• cordis upstream framework https://github.com/cordiverse/cordis

Accepts as evidence

• official docs
• tagged release
• github release
• maintainer commit
• merged pr
• package registry release
• maintainer authored post
• maintainer discussion answer
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• marketing claim without doc or code
• star count as adoption

Default actionability

release

observe

prerelease

observe

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

first stable release

test

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy

Research lenses

• provider first party harness
• plugin architecture
• capability
• security
• ecosystem

High-signal patterns

plugin / dsh-plugin / cordis / capability seam / sandbox / permission / approval / api gateway / agent lifecycle / session / storage / scheduling / loop / web ui / rc / developer preview / breaking change / stable

Operator questions

• The only tag is a release candidate and the npm latest dist-tag points at it: is there any channel an operator can install that is not a prerelease?
• The README states in capitals that there will be compatibility-breaking changes. Which surfaces are covered by that warning, and is the plugin API among them?
• If everything is a plugin, what enforces a plugin's limits, and can a plugin replace the component that would have refused it?
• The Web UI binds 127.0.0.1:3080 by default. What authenticates a request to it, and what happens when an operator exposes that port?
• Issues are disabled and a .gitlab-ci.yml is committed. Is the public GitHub repo the development home or a mirror, and where does an operator report and track a defect?
• Docs ship English and Chinese side by side with i18n yaml. When the two disagree, which one is normative?
• Cordis defines the plugin paradigm. Which behaviours does an operator inherit from Cordis rather than from DeepSeek, and who ships a fix when one of them breaks?
• Does the harness run any model other than DeepSeek's own, and is that a supported path or an incidental one?

Discovery state

last verified: 2026-08-17 / manual web / medium confidence

• What is the canonical ship signal, the GitHub release, the tag, or the npm publish? All three currently point at the same rc.
• Is there a published stabilisation target or date for 0.1.0 proper?
• Which parts of the architecture are plugin boundaries in fact rather than in the README's claim?
• Does an internal GitLab pipeline gate what lands here, and does that make the public commit history a partial record?

Primary surfaces

• repo github repo https://github.com/anomalyco/opencode
  watch: tags / commits / pull requests / issues / configuration / permissions / policies / providers / session storage / plugins

  GitHub repository ID 975734319. The former sst/opencode API resolves to this same ID and full_name. Default branch is dev, not main. Resolve a change against the relevant release tag; branch presence is not shipment.

• docs-v2 official docs https://opencode.ai/v2/docs
  watch: permissions / policies / agents / migrate from v1 / config / compaction / references / plugins / mcp / cli / api / console

  Current documentation family. At intake the stable snapshot is https://github.com/anomalyco/opencode/tree/v2.1.4/services/www/src/docs/content. Pin the source commit for historical defaults; do not substitute V1 docs.

• docs-v1 official docs https://opencode.ai/docs/
  watch: permissions / agents / server / web / share / sdk / providers

  OpenCode 1 documentation remains live. The V1 README at v1.19.4 links this family and opencode-ai. Its permission keys and server behavior must not be carried into V2 without checking the V2 record.

• changelog official changelog https://opencode.ai/changelog
  watch: versioned changes / breaking changes / core / tui / desktop / sdk / extensions

  V2.1.4 is dated 2026-10-23 here. Corroborate the entry with registry publication and its source tag; a changelog date alone is not ancestry.

• npm-v2 package registry https://www.npmjs.com/package/@opencode/cli
  watch: latest / beta / dev / publication time / integrity / repository identity / platform packages

  Current stable CLI package, confirmed by the v2.1.4 README and registry repository metadata. Resolve npm view @opencode/cli dist-tags, then read the exact version and its time entry from https://registry.npmjs.org/@opencode%2fcli. At intake latest is 2.1.4, published 2026-10-23T10:13:53.203Z. Dereference refs/tags/v2.1.4 through gh api; it resolves to commit 68bc26b7da1990ce10ffecfbc1e09eb13aa5d824. A matching npm publication and source tag establish tagged-release even without a GitHub Release object.

• npm-v1 package registry https://www.npmjs.com/package/opencode-ai
  watch: latest / dev / beta / historical dist tags / publication time / integrity

  Still the OpenCode 1 package, not an alias for the newest major. Resolve npm view opencode-ai dist-tags and https://registry.npmjs.org/opencode-ai. At intake latest is 1.19.4, published 2026-10-22T13:03:43.704Z. Old latest-0, latest-1, snapshot, next and beta pointers can be stale; record the resolved version and time rather than interpreting the name as fresh.

• github-releases github releases https://github.com/anomalyco/opencode/releases
  watch: release publication / prerelease flag / assets / updater manifests

  gh api repos/anomalyco/opencode/releases/latest resolves to v1.19.4, published 2026-10-22T13:03:41Z. It is not the global newest stable: V2.1.4 has a source tag and npm publication but its GitHub Release lookup returned 404 at intake. Distinguish tag, release object, npm package and downloadable artifact. The V1 tag dereferences to 148842ef7cb1bc34192b3fff57d0f9721ab9c801; the Release target_commitish field is not a substitute for dereferencing the tag.

• release-pipeline tagged source https://github.com/anomalyco/opencode/blob/v2.1.4/script/publish.ts
  watch: stable tag creation / preview channel resolution / npm publication / desktop publication / updater publication

  Also inspect packages/script/src/index.ts, packages/cli/script/publish.ts, script/update-artifact.ts and .github/workflows/publish.yml at the same commit. V2 distributes artifacts through the official update service; GitHub Releases alone is incomplete. For a change, compare its commit with the dereferenced tag using GitHub compare merge_base_commit or a read-only ancestry check, then verify the package or artifact channel.

• desktop official downloads https://opencode.ai/download
  watch: desktop beta status / operating system / architecture / artifact version / updater channel / bundled server

  The v2.1.4 README labels Desktop App BETA and links this download page. Desktop product status is separate from CLI stable SemVer and from npm beta. Resolve each download or updater manifest to its version, platform and hash before assigning a fix to a desktop installation. A source workflow or a V1 release asset does not establish the current V2 binary.

• permissions-v2 tagged source https://github.com/anomalyco/opencode/blob/v2.1.4/services/www/src/docs/content/permissions.mdx
  watch: permissive defaults / external directory / shell scanner / saved approvals / subagent authority / global and agent rules / policy precedence
• security-policy security policy https://github.com/anomalyco/opencode/blob/v2.1.4/SECURITY.md
  watch: no sandbox / server threat model / mcp trust boundary / provider data handling

  Explicitly says permissions are a UX feature, not security isolation. Its server-password description differs from the V2 web documentation; preserve the disagreement until the relevant launch path is traced.

• advisories security advisories https://github.com/anomalyco/opencode/security/advisories
  watch: affected ranges / fixed versions / bundled runtime / cli desktop and server scope
• web-v2 official docs https://opencode.ai/v2/docs/cli/web
  watch: local server / pairing / generated password / session cookie / remote tunnel / standalone serve

  A browser client for an operator-run server. Pairing and OpenTunnel access are not evidence that execution moved to a hosted agent runtime. Pin services/www/src/docs/content/cli/web.mdx for dated claims.

• console official service https://opencode.ai/console
  watch: inference gateway / workspaces / provider accounts / budgets / organization policies / sso / data handling

  Optional hosted service documented at https://opencode.ai/v2/docs/console. Watch Zen at https://opencode.ai/docs/zen/ and Go at https://opencode.ai/docs/go/ as model-service surfaces, separately from local execution. Hosted service changes need dated service receipts; a CLI tag does not pin a later rollout, price, model list or retention policy.

• share-v1 official docs https://opencode.ai/docs/share/
  watch: public session links / manual auto disabled / uploaded conversation data / unshare and retention

  V1 docs describe optional hosted public conversation links at opncd.ai. Do not generalize the feature or its defaults to V2 without a V2 receipt.

• site official site https://opencode.ai/
  watch: positioning / installation targets / provider support / surface changes

  The site links the canonical repo and V2 docs. Marketing usage totals are attributed claims, not independently established active-user counts.

• team maintainer roster https://github.com/anomalyco/opencode/blob/v2.1.4/.github/TEAM_MEMBERS
  watch: maintainer changes / maintainer explanations

  Confirmed GitHub handles include thdxr, jayair, Hona and Brendonovich. The same tag's .github/CODEOWNERS names Hona and Brendonovich for web and desktop packages. npm view names thdxr as package maintainer. These receipts establish GitHub/npm handles, not matching X identities.

• social-x official social https://x.com/opencode
  watch: announcements / maintainer context / primary receipt links

  Linked by the tagged README and official homepage. A post proves what the account said; verify product claims through docs, source or releases.

• discord official community https://opencode.ai/discord
  watch: public announcements / links to primary records

  Official README link; it also names https://discord.gg/opencode. Private discussion and screenshots without a public primary receipt are not evidence.

Related surfaces

watched

Keep the Anomaly project, its package generations, and the separate Go lineage distinct. OpenTunnel supplies remote connectivity, not proof of sandboxing. Related SDK, plugin and editor integrations require their own package or extension version before calling an integration shipped.

• opencode primary https://github.com/anomalyco/opencode
• sst-opencode former namespace same repository id https://github.com/sst/opencode
• opencode-beta historical preview distribution not stable authority https://github.com/anomalyco/opencode-beta
• opentunnel v2 remote connectivity https://github.com/anomalyco/opentunnel
• old-go-opencode excluded distinct archived go project https://github.com/opencode-ai/opencode
• crush successor to excluded go project https://github.com/charmbracelet/crush

Accepts as evidence

• official docs
• tagged release
• tagged commit file
• github release
• maintainer commit
• merged pr
• package registry release
• versioned official changelog
• dated official service record
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• marketing claim without doc or code
• star count as active adoption
• package downloads as unique users
• crush or old go opencode as anomaly evidence
• github latest badge as global latest
• moving docs as historical defaults
• merged code as released binary
• permission prompt or plan label as sandbox

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

pricing or usage change

observe

policy or permission change

test

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy

Research lenses

• provider portability
• authority and isolation
• human attention
• client server boundary
• durable state
• distribution channel
• harness extensibility
• inference economics

High-signal patterns

permissions / policies / external_directory / shell scanner / saved approval / subagent / plan / sandbox / pair / OpenTunnel / server password / Console / Zen / Go Plus / provider / subscription / MCP / ACP / plugin / compaction / session import / migration / worktree / upgrade

Operator questions

• Which package, major, tag, client and server does the operator actually run, and does the claimed change reach that combination?
• What may Build, Plan and each subagent do by default, which approvals persist, and which global or Console policy can prevent a project from granting access?
• Does a permission or directory rule merely mediate a tool call, or is there an independently enforced filesystem, process or network boundary?
• What work moves through the server, SDK, plugins, MCP and editor clients, and where do credentials, session state and verification remain the operator's responsibility?
• Does changing providers preserve useful context and completed work, or create replay, authentication, compatibility and review costs?
• Which inference, sharing or remote-access surface sends data off the host, under whose policy, and can the operator disable it?
• Does broader delegation reduce human approval and review time per verified outcome, or simply produce more work for the same person to inspect?

Discovery state

last verified: 2026-10-24 / gh api npm view registry api and tagged source review / high confidence

Two separate identity changes matter. sst/opencode resolves to anomalyco/opencode with GitHub ID 975734319. The distinct archived Go repository opencode-ai/opencode has ID 949662713 and directs users to charmbracelet/crush. Separately, Anomaly's current stable V2 package is @opencode/cli, while opencode-ai continues the V1 line; @opencode-ai/cli is an older preview package and is not the current stable package name.

• Which desktop updater artifacts currently correspond to V2 stable, beta and older V1 installations, with what platform hashes?
• Which V2 server launch paths generate and require a password, and why does the tagged SECURITY.md retain the older opt-in-password description?
• Do V2 permission, saved-approval and Console-policy implementations enforce every documented boundary across shell, plugins, MCP and subagents?
• What survives a V1-to-V2 upgrade across session imports, agent configuration, plugins, SDK clients and provider authentication?
• What measured end-to-end workflow demonstrates less human attention per verified outcome, and what inference and review costs does it add?

Primary surfaces

• repo github repo https://github.com/withastro/flue
  watch: commits / releases / tags / pull requests / readme / changelog / examples / docs
• changelog changelog file https://github.com/withastro/flue/blob/main/CHANGELOG.md
  watch: versions / breaking changes / new features / fixes

  Canonical receipt surface. Flue publishes no GitHub Releases (github.com/withastro/flue/releases is empty), so cite the version-tagged CHANGELOG.md (or a release tag) as the receipt, never the /releases page. Surfaced by the 2026-05-28_2026-06-03 run audit (item 2).

• homepage official site https://flueframework.com/
  watch: framing / feature surface / deployment targets / skill system / sandbox api

Accepts as evidence

• github commit
• github release
• tagged release
• merged pr
• readme change
• official docs
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• seo clone or mirror

Default actionability

release

observe

docs change

observe

api change

study

breaking change

note

ecosystem package

observe

philosophy change

study

Change types

• capability
• api surface
• runtime
• sandbox
• skill system
• deployment
• protocol
• philosophy
• ecosystem
• security
• breaking change

Research lenses

• agent harness architecture
• model harness separation
• programmable runtime
• headless agent
• sandbox design
• skill primitives
• session memory
• ci deployment
• filesystem abstraction

High-signal patterns

model + harness separation / programmable harness / headless agent / sandboxed execution / skill system / markdown skills / AGENTS.md / session management / memory / filesystem abstraction / HTTP server / CLI agent / CI/CD deployment / Cloudflare Workers / API change / breaking change / experimental

Operator questions

• Does this validate or challenge the "model + harness" framing as a durable public category?
• Which harness primitives (sandbox, filesystem, skills, memory, sessions, credentials) are stabilizing vs. still experimental?
• Does this suggest integration surfaces teams should expose, wrap, or treat as precedent?
• Does any API change affect how operators should think about their own receipt layer or deployment membrane?
• Is the project gaining enough traction to treat as architectural reference rather than just category evidence?

Discovery state

last verified: 2026-06-03 / harvest run / medium confidence

• Confirm GitHub repo is github.com/withastro/flue (withastro org is unusual for an agent harness project; verify ownership).
• Is the Apache-2.0 license confirmed in the repo?
• What is the actual star count and commit velocity at time of first harvest?
• Are APIs stable enough to treat individual primitives as architectural precedent, or watch-only for now?

Primary surfaces

• homepage https://eve.dev
• repo github repo https://github.com/vercel/eve
  watch: commits / releases / tags / pull requests / readme / changelog / examples
• releases github releases https://github.com/vercel/eve/releases
  watch: versions / breaking changes / new features / fixes

  Canonical receipt surface. Eve ships tagged GitHub Releases with per-release notes (e.g. eve@0.10.0, eve@0.11.5). Cite the release tag and its notes as the receipt for a version-level change; cite the docs for architectural claims and the Vercel changelog for the launch itself.

• docs official docs https://eve.dev/docs
  watch: framing / project layout / tools / skills / channels / schedules / subagents / connections / sandbox / hooks / durable execution
• changelog vendor changelog https://vercel.com/changelog/introducing-eve-an-open-source-agent-framework
  watch: launch framing / positioning

Accepts as evidence

• github release
• tagged release
• github commit
• merged pr
• readme change
• official docs
• maintainer authored post
• vendor changelog
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• seo clone or mirror

Default actionability

release

observe

docs change

observe

api change

study

breaking change

note

approval gate change

study

sandbox change

study

philosophy change

study

Change types

• capability
• api surface
• runtime
• sandbox
• skill system
• subagents
• connections
• durable execution
• approval gates
• deployment
• protocol
• philosophy
• ecosystem
• security
• breaking change

Research lenses

• agent harness architecture
• filesystem first agents
• durable execution
• human in the loop approval
• sandbox design
• subagent delegation
• mcp connections
• skill primitives
• session recovery
• gateway credentials

High-signal patterns

filesystem-first agent / agent is a directory of files / durable execution / resumable sessions / crash-safe / human in the loop / approval gate / tool call denied / sandbox backend / Microsandbox / Docker sandbox / subagent delegation / MCP connection / skills / schedules / channels / AI Gateway / OIDC / breaking change / public beta

Operator questions

• Does Eve's approval-gate model change how teams gate tool calls before an agent proceeds?
• Which primitives (sandbox backends, durable sessions, subagents, connections, approval gates) are stabilizing versus still moving on a fast beta?
• Does the filesystem-first "agent is a directory of files" model make agent definitions more portable, reviewable, or version-controllable than code-first frameworks?
• How does durable, resumable execution on the Workflow SDK change what operators can promise about crash recovery and human pauses mid-run?
• Is the project stable enough to treat individual primitives as architectural precedent, or watch-only while the beta churns?

Discovery state

last verified: 2026-06-19 / harvest run / medium confidence

• How stable is the public API across the rapid 0.10..0.11 release cadence (eight releases in the first days)?
• Which of the three sandbox backends (Vercel, Microsandbox, Docker) are first-class versus best-effort in practice?
• What does the human-in-the-loop approval surface look like end to end (who approves, where the pause is recorded, what an operator sees)?
• Does the Workflow SDK dependency constrain where Eve agents can be hosted and recovered?

Primary surfaces

• repo github repo https://github.com/Dicklesworthstone/agentic_coding_flywheel_setup
  watch: releases / tags / readme / docs

  Weekly change detection is release- and tag-bounded -- NOT commits or pull requests. README and docs claims are accepted only when pinned to a tag or its dereferenced commit. The repo had 3,440 main-branch commits at the 2026-07-02 intake against 7 tagged releases; the tag is the receipt surface that keeps this source finite. Never cite a moving main URL for a historical posture claim.

• homepage official site https://agent-flywheel.com/
  watch: methodology / cost transparency / agent lineup / installer claims / security posture

Related surfaces

context only not weekly harvest

A selected set of repositories that implement the operating loop may be studied in explicitly scoped, dated work. This list is not the maintainer's complete portfolio, and these repositories are not silently promoted into weekly Agent Flywheel findings.

• mcp-agent-mail-rust coordination and audit https://github.com/Dicklesworthstone/mcp_agent_mail_rust
• beads-rust task and dependency state https://github.com/Dicklesworthstone/beads_rust
• beads-viewer graph aware work ranking https://github.com/Dicklesworthstone/beads_viewer
• ntm session orchestration https://github.com/Dicklesworthstone/ntm
• coding-agent-session-search cross harness session history https://github.com/Dicklesworthstone/coding_agent_session_search
• cass-memory procedural memory https://github.com/Dicklesworthstone/cass_memory_system
• dcg deterministic command guard https://github.com/Dicklesworthstone/destructive_command_guard
• slb human approval for dangerous commands https://github.com/Dicklesworthstone/slb

Related research

• agentic-very-much-v1 context only individual account repository count https://arxiv.org/abs/2606.07448v1

Accepts as evidence

• tagged release
• github release
• tagged readme or docs
• attributed official site claim for current posture
• attributed project authored budget
• contextual primary research paper
• maintainer authored post with primary receipt
• reproducible local probe

Refuses to promote

• unspecified portfolio wide claim
• untagged main branch commits
• unsourced social claim
• third party summary without primary link
• self reported metric presented as independent fact
• speculation
• stale model memory
• duplicate commentary
• seo clone or mirror

Default actionability

release

study

docs change

observe

defaults change

note

security

note

cost change

observe

ecosystem package

ignore

Change types

• defaults
• security
• capability
• cost
• distribution
• agent lineup
• breaking change
• ecosystem
• license

Research lenses

• assembly layer
• default setting authority
• installer trust
• cost of operation
• multi agent cohabitation
• individual account repository output
• durable state outside provider harnesses
• human liaison work
• agent native interfaces
• memory and feedback loops

High-signal patterns

install.sh behavior change / default settings written for Claude Code / Codex / Antigravity / permission or auto-mode posture set by the installer / credential, token, or session handling / version or channel pins for the bundled agents / agent added to or dropped from the lineup / sudo or system-level configuration change / safety-tool enforcement vs. advice / published cost figures updated

Operator questions

• What defaults does the installer set across the three bundled tier-1 agents, and would their own vendors ship those defaults?
• Does the installer pin agent versions and channels? An assembly layer inherits the released-is-not-merged problem for every tool it bundles.
• Where do credentials and session state land on the VPS, and who can read them?
• Do the bundled "safety tools" enforce anything, or advise? A warning is not a boundary.
• Are the project's attributed operating-budget examples ($440-656/month at intake, including a two-Claude-account high end) holding as the lineup changes?
• Does the plan-to-graph-to-coordination loop reduce total human attention across a completed project, or create new maintenance and review queues?
• Does the OpenAI/Anthropic license rider apply to the operator or intended use? Potentially covered parties should review the tagged LICENSE and obtain their own legal guidance.

Discovery state

last verified: 2026-07-12 / exemplar and receipt audit / high confidence

• Does the next tag make safe mode gate the dangerous Claude, Codex, and Antigravity shortcuts, remove ACFS-created NOPASSWD state when changing modes, and detect provider-supplied passwordless sudo?
• Which bundled agent versions and release channels are pinned, and which still float with upstream latest installs?
• What measured evidence would show that the coordination and memory loop improves verified outcomes per unit of human attention?
• Will the non-standard OpenAI/Anthropic license rider change, and which operators need to obtain separate permission?

Primary surfaces

• repo github repo https://github.com/omnigent-ai/omnigent
  watch: releases / tags / commits / pull requests / breaking changes / security
• releases official release notes https://github.com/omnigent-ai/omnigent/releases
  watch: new features / policy changes / routing changes / breaking changes / deprecations
• changelog official changelog https://github.com/omnigent-ai/omnigent/blob/main/CHANGELOG.md
  watch: unreleased section / fixes / breaking changes
• advisories security advisories https://github.com/omnigent-ai/omnigent/security/advisories
  watch: published advisories / severity / affected ranges
• docs official docs https://omnigent.ai/docs
  watch: policies / permissions / sandboxing / spend caps / harness adapters / routing / sessions / teams / deployment
• landing official docs https://omnigent.ai
  watch: positioning / feature list / differentiation

Related surfaces

watched

Omnigent drives harnesses this publication already tracks separately. Behaviour observed through it is a fact about the pair, never about either component alone, and a finding must say which.

• omnigent primary https://github.com/omnigent-ai/omnigent

Accepts as evidence

• official docs
• tagged release
• github release
• maintainer commit
• merged pr
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• marketing claim without doc or code

Default actionability

release

test

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

governance change

test

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy

Research lenses

• governance
• coordination control plane
• productized agent platform
• capability
• economics

High-signal patterns

policy / deny / allow / approval / spend cap / budget / quota / access control / adapter / harness / router / routing / sandbox / isolation / session sync / transcription / scheduled task / automation / project / team / breaking change

Operator questions

• When an Omnigent policy and the underlying harness's own permission system disagree, which one refuses, and is that documented or only observed?
• Are spend caps enforced before a call is made, or reconciled after it? A cap that reconciles is a report, not a control.
• When a wrapped harness changes a permission surface, how long does the adapter lag, and what does an operator's policy mean during the gap?
• The v0.7.0 router picks both harness and model. Can the governance layer an action lands under change without the operator choosing it?
• Server-side transcription is a data path off the operator's machine. What is sent, what is retained, and is it opt-in?
• Is the governance work in the tag an operator installs, or on main?
• Pre-1.0 and shipping weekly: what is the upgrade contract, and what breaks between minors?

Discovery state

last verified: 2026-08-02 / manual web / medium confidence

• Which policy decisions are enforced in Omnigent's process versus delegated to the wrapped harness?
• Does the adapter surface a harness's own refusal to the operator, or swallow it?
• What is the canonical ship signal - the GitHub release, the tag, or a package publish?
• Which of the governance features in the landing copy are on by default?

Primary surfaces

• homepage https://omp.sh/
• repo github repo https://github.com/can1357/oh-my-pi
  watch: releases / tags / commits / pull requests / breaking changes / security / contribution policy
• releases official release notes https://github.com/can1357/oh-my-pi/releases
  watch: new features / breaking changes / tag without release / deprecations / upstream divergence
• changelog official changelog https://github.com/can1357/oh-my-pi/blob/main/packages/coding-agent/CHANGELOG.md
  watch: unreleased section / fixes / breaking changes
• npm package registry https://www.npmjs.com/package/@oh-my-pi/pi-coding-agent
  watch: dist tags / package version / version lag behind tags / scope collision with upstream
• advisories security advisories https://github.com/can1357/oh-my-pi/security/advisories
  watch: published advisories / severity / affected ranges
• docs official docs https://omp.sh/docs
  watch: lsp / dap / subagents / plan mode / hindsight memory / hashline edits / rules / permissions / sandboxing / providers / relay sessions / extensions
• install-script install channel https://omp.sh/install
  watch: resolved version / platform matrix / integrity verification
• site-changelog official changelog https://omp.sh/changelog
  watch: public framing / divergence from repo changelog

Related surfaces

watched

OMP states in its README that it is a fork of Pi by Mario Zechner, and Pi is already on this watchlist as pi-coding-agent. Findings must not be laundered between them. A behaviour observed in OMP is a fact about OMP unless the code path is shown to be shared, and an upstream Pi change is not an OMP change until it lands in a tag OMP publishes. Note also that the README links badlogic/pi-mono, the pre-migration upstream, while Pi's canonical repo is now earendil-works/pi.

• oh-my-pi primary https://github.com/can1357/oh-my-pi
• pi-mono declared fork origin https://github.com/badlogic/pi-mono
• pi upstream current https://github.com/earendil-works/pi

Accepts as evidence

• official docs
• tagged release
• github release
• maintainer commit
• merged pr
• package registry release
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• marketing claim without doc or code
• upstream pi behaviour assumed to hold in omp

Default actionability

release

observe

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

upstream divergence

observe

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy

Research lenses

• fork divergence
• ide integration
• capability
• distribution channel
• maintainership

High-signal patterns

lsp / dap / debugger / hashline / hindsight / plan mode / subagent / rules / relay / session share / permission / approval / sandbox / provider / rust core / breaking change / vouch / upstream

Operator questions

• The fork publishes @oh-my-pi/pi-coding-agent at 17.x while upstream Pi publishes @earendil-works/pi-coding-agent at 0.8x: does anything an operator runs resolve the wrong package basename by scope confusion?
• Two tags exist with no GitHub release and npm latest sits at the last released tag. Which of the four install paths, script, Homebrew, Bun, and Nix, resolve to the same version on the same day?
• At better than one release a day, what is the upgrade contract, and where is a breaking change announced other than the changelog?
• LSP and DAP mean the agent drives a language server and a live debugger. What confines those, and does a debugger session widen what the agent can execute past whatever the tool permission layer allows?
• Relay sessions put a live session behind a link and a QR code. Who can join, what does a joiner see, and is the relay operated by the maintainer?
• Hindsight memory and time-traveling rules both change agent behaviour from stored state. What writes that state, and can a repository under review write it?
• The PR vouch requirement is lifted "temporarily as a trial." What is the review gate on a single-maintainer project carrying roughly 80k lines of Rust, and what happens when the trial ends?
• Where does an OMP capability actually come from, its own Rust core or inherited Pi code, and does the answer change who fixes it?

Discovery state

last verified: 2026-08-17 / manual web / medium confidence

• Is there a stated compatibility relationship with upstream Pi, or is the fork now fully independent?
• Which surface is canonical for a shipped version, the GitHub release, the tag, the npm dist-tag, or the install script?
• Does the Homebrew tap or the Nix flake ever lead or lag the npm publish?
• Is the relay a maintainer-operated service, and what does it retain?

Primary surfaces

• repo github repo https://github.com/temporal-community/temporal-agent-harness
  watch: releases / tags / commits / pull requests / breaking changes / security / codeowners / main ahead of tag
• releases github releases https://github.com/temporal-community/temporal-agent-harness/releases
  watch: new features / breaking changes / prerelease flag / tag without pypi publish / deprecations

  This is the only changelog. There is no CHANGELOG file in the tree and the PyPI metadata points its Changelog link here.

• pypi package registry https://pypi.org/project/temporal-agent-harness/
  watch: package version / version lag behind tags / extras / python requires / temporalio floor / development status classifier
• docs-internal official docs https://github.com/temporal-community/temporal-agent-harness/tree/main/docs/internal
  watch: tool approvals / agents as subagents / event stream / core concepts / what the harness adds / development
• coding-example official docs https://github.com/temporal-community/temporal-agent-harness/tree/main/examples/callback_tools/coding_agent
  watch: opencode shim / callback tools / approval mapping / local tool execution / inherently safe declarations / subagent wiring

  The one place this harness is a coding agent. A remote workflow reasons, a shim on the laptop runs bash, read, write, edit, grep and glob after an OpenCode permission prompt, and the shim speaks OpenCode's internal protocol, which the README says shifts between releases.

• advisories security advisories https://github.com/temporal-community/temporal-agent-harness/security/advisories
  watch: published advisories / severity / affected ranges
• publish-workflow ci workflow https://github.com/temporal-community/temporal-agent-harness/blob/main/.github/workflows/publish.yml
  watch: trusted publisher / tag version check / required reviewers / test gate

  Publishes to PyPI on a GitHub release via OIDC trusted publishing. Runs the test suite and refuses a tag whose pyproject version disagrees. The pypi environment has no required reviewer as of intake; the file itself says that is where a human gate would go.

• docs-design official docs https://github.com/temporal-community/temporal-agent-harness/tree/main/docs/design
  watch: codeact as toolset / observable agent state / unified message dispatch / per message events

Related surfaces

watched

The harness sits on the Temporal Python SDK and inherits its execution semantics. A durability claim in the README is a claim about the pair, and a finding must say whether the behaviour comes from the harness, from the SDK, or from the Temporal service the operator runs it against. The OpenAI Agents integration is vendored from sdk-python main, so a defect there may already be fixed upstream and not here, or the reverse. Code Mode runs inside pydantic-monty, a third-party sandbox, and a sandbox finding must name it. OpenCode is not on this watchlist; it appears here only as the front end the coding example attaches to.

• temporal-agent-harness primary https://github.com/temporal-community/temporal-agent-harness
• sdk-python upstream sdk and vendored source https://github.com/temporalio/sdk-python
• pydantic-monty code mode sandbox https://pypi.org/project/pydantic-monty/
• temporal-community hosting org disclaims support https://github.com/temporal-community

Accepts as evidence

• official docs
• tagged release
• github release
• package registry release
• maintainer commit
• merged pr
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• marketing claim without doc or code
• temporal platform guarantee assumed to cover tool side effects
• main branch readme treated as released behaviour

Default actionability

release

observe

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

approval policy change

test

protocol change

observe

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy

Research lenses

• durable execution
• approval policy
• remote reasoning local side effects
• vendor first party harness
• distribution channel
• capability

High-signal patterns

approval / approval policy / inherently_safe / remember / dangerously_skip_all / dangerously_allow_all / callback tool / code mode / sandbox / monty / subagent / replay / event stream / workflow history / payload offload / S3 / Temporal Cloud / session manager / opencode / shim / nexus / breaking change / prerelease / pin

Operator questions

• The approval policy's remember flag allow-lists a tool by name and cascades to every pending call of that tool. In the coding example, does OpenCode's 'always' map to it, so that one 'always' on bash approves every later command with any arguments?
• Layer zero of the policy is dangerously_skip_all_approvals, and a caller can override the agent's default policy per session through AgentConfig.approval_policy, with the caller winning. Who can start a session, and can a session starter hand themselves a policy the agent author never chose?
• Relaxing a live policy re-evaluates calls already parked at the gate and releases the ones the new policy allows. Does the operator who relaxes it see what is about to run, or does the release happen against calls queued before the change?
• The README says an agent resumes mid-turn with no double-run tool calls. Temporal retries activities by policy. What does an activity-backed tool have to be for that to hold, and does anything in the harness enforce it?
• Every turn, tool call and reply token is recorded in workflow history and is replayable. Against Temporal Cloud, that history, and any payload offloaded to S3, leaves the operator's machine. What is in it, what is retained, and who can read it?
• The coding example puts reasoning on a remote worker and side effects on the laptop through a shim that speaks OpenCode's internal protocol, which the README says shifts between releases. When it shifts, does the approval prompt fail closed, or does the shim's mapping degrade silently?
• Tags 0.1.0 and 0.2.0 exist with no PyPI publish; 0.3.0 and 0.4.0 have one. Every GitHub release is flagged prerelease. Which channel is canonical for a shipped version, and does 'pin to a release' mean the tag or the wheel?
• The README on main documents a message-dispatch model with per-handler mid-turn modes that the README at the 0.4.0 tag does not mention. Which of the dispatch semantics are in the wheel an operator installs today?
• The agent_interface query returns every handler by design, and the docs say a parent's SubagentToolPolicy is what actually narrows reach. What does dangerously_allow_all expose that the model_callable hints would have kept back, and is that visible to the operator of the parent?
• The repo lives in an org whose description says its repos have no guarantee of support or maintenance, while the README and pyproject name Temporal Technologies as the author. Which statement governs when something breaks?

Discovery state

last verified: 2026-09-22 / manual web / medium confidence

• Which surface is canonical for a shipped version, the GitHub release, the tag, or the PyPI wheel, given that the two earliest tags never reached PyPI?
• Does self-hosted Temporal versus Temporal Cloud change what the workflow history retains and who can read it?
• Will the OpenCode shim track OpenCode releases, or is it a demonstration that will drift?
• The README says sdk-python has fully supported non-harness integrations for Gemini and the OpenAI Agents SDK. What is the intended relationship between those and this harness?
• Is there a path from temporal-community to a supported temporalio repository, and what would change for an operator when it moves?

Primary surfaces

• homepage https://unreallabs.ai
• docs https://github.com/unreallabsai/unreal-agent/blob/main/README.md
• repo github repo https://github.com/unreallabsai/unreal-agent
  watch: releases / tags / commits / breaking changes / security / contribution policy / components published from internal codebase
• releases github releases https://github.com/unreallabsai/unreal-agent/releases
  watch: new features / breaking changes / session format version / operation version
• docker-image package registry https://hub.docker.com/r/unrea1labs/unreal-agent
  watch: tags / namespace / digest per release

  The official image namespace is unrea1labs, with a digit one, as published by .github/workflows/release.yml. The look-alike namespace unreallabs returned 404 on 2026-09-23. Name the namespace and digest in any finding.

• runner-docs official docs https://github.com/unreallabsai/unreal-agent/blob/main/cmd/unreal-agent-runner/README.md
  watch: providers / default system prompt / tool set / workspace / egress proxy
• advisories security advisories https://github.com/unreallabsai/unreal-agent/security/advisories
  watch: published advisories / severity / affected ranges
• benchmarks official docs https://github.com/unreallabsai/unreal-agent/tree/main/benchmarks
  watch: harbor adapter / published scores / method

Related surfaces

watched

The repository says it carries selected components from a larger internal codebase, and it does not merge outside pull requests. A gap in public history is not evidence of no work. The openai-codex provider reads a ChatGPT subscription login from the Codex auth file; behaviour observed through that path is a fact about this runner, not about Codex.

• unreal-agent primary https://github.com/unreallabsai/unreal-agent
• codex credential source for openai codex provider https://github.com/openai/codex

Accepts as evidence

• official docs
• tagged release
• github release
• maintainer commit
• merged pr
• package registry release
• maintainer authored post
• reproducible local probe

Refuses to promote

• unsourced social claim
• third party summary without primary link
• speculation
• stale model memory
• benchmark claim without method
• duplicate commentary
• marketing claim without doc or code
• star count as adoption
• system prompt claim treated as enforced isolation

Default actionability

release

observe

docs change

observe

security change

test

breaking change

adapt

ecosystem package

observe

benchmark claim

observe

Change types

• capability
• workflow
• runtime
• protocol
• reliability
• economics
• security
• ecosystem
• evaluation
• philosophy

Research lenses

• thin harness
• durable execution
• idempotency
• remote execution
• evaluation
• distribution channel

High-signal patterns

approval / sandbox / egress / SANDBOX_EGRESS_PROXY / operation manager / remote job / session fork / session version / idempotent / inbox / compaction / context builder / skill / openai-codex / auth.json / harbor / terminal-bench / docker / breaking change

Operator questions

• The default system prompt tells the model it is inside an isolated sandbox container, and the README's first example runs the runner directly in the current directory. Is there any check that refuses to run outside a container, and does the model behave differently because it believes it is contained?
• The tool registry holds Bash, ViewImage and skill use, with no approval step visible in the library. Where would an operator put a human or policy gate, and does the operation manager boundary make that a supported seam?
• Operations are serializable and a proxy operation manager can ship them to a remote sandbox. What authenticates the remote side, and what does it accept?
• The openai-codex provider reads a ChatGPT subscription token from the Codex auth file and does not refresh it. Is that use within the subscription's terms, and what happens to a long run when the token expires?
• The org describes its aim as making agents better and cheaper through harness engineering. Which published benchmark results back that, with what method and which models?
• Session history is versioned and forkable, with an explicit error on unsupported versions. Does a runner upgrade ever strand an in-flight session?

Discovery state

last verified: 2026-09-23 / manual web / medium confidence

• Does any runner code check for a container before running Bash, or is isolation left entirely to the operator?
• Which components of the internal codebase are withheld, and do they include a policy or approval layer?
• Will Unreal Labs publish benchmark results with method, and on which suite?
• Will the look-alike Docker Hub namespace be claimed by the vendor?