Coding Agents Are Becoming Working Environments

The last two weeks were not about one coding agent pulling ahead. They were about the layer around coding agents getting more serious.

By harness, I mean the practical wrapper around the model: the CLI, permission system, memory surface, sandbox, plugin layer, review flow, and runtime assumptions that determine what the agent can actually do.

Codex added persistent goals. Claude Code pushed deeper into cloud review, session recaps, plugins, hooks, MCP, and telemetry. Gemini CLI tightened workspace trust and environment loading while experimenting with reviewable memory patches. Hermes added a background Curator for skill maintenance. Pi kept proving the other side of the market: a small terminal harness can move quickly by keeping the core thin.

The through line is simple: coding agents are becoming less like chat boxes and more like working environments.

That is useful, but it also raises the stakes. If the agent can remember, review, load plugins, carry goals, and run under different permission modes, then serious developers need to know which of those surfaces shaped the work.

The Signals

Persistent goals move coding agents beyond single sessions

Codex /goal is the strongest signal in this window. It gives the agent something more durable than a prompt: a persistent objective it can carry across a longer arc of work.

That matters because long-horizon development is not just a code-generation problem. It is an orientation problem. The agent has to stay pointed in the right direction across sessions, reviews, interruptions, and course corrections.

The new question is not "can the agent remember?" It is "what goal is it pursuing, and who decided that goal is still the right one?"

For Bitter, the answer should be conservative: use agent goals, but record which goal was active and reconcile it against the project charter and current task before treating it as durable project memory.

Supported by:

• Codex

Agent memory is becoming a product surface

Claude session recaps, Gemini Auto Memory, and Hermes Curator all point in the same direction: agent tools are learning how to carry context forward.

That is good. It also means memory is no longer one thing. A serious run may now be shaped by chat history, session recaps, generated memory patches, skill reports, resume state, and local project notes.

Bitter should not fight those surfaces. It should record which agent-side memory affected a run, then decide what deserves to become part of the project's durable record.

Supported by:

• Claude Code
• Gemini CLI
• Hermes Agent

Permissions are getting clearer, but every agent does them differently

Codex expanded permission profiles and sandbox metadata. Gemini added secure .env loading, workspace trust, and shell allowlists. Claude Code kept moving around plugins, hooks, MCP, telemetry, and permission prompts. Pi's provider and extension layers changed quickly.

The direction is good: agents are exposing more of the authority they run with. The problem is fragmentation. Every tool names and scopes that authority in its own way.

For serious work, "the agent had access" is not enough. The useful question is more specific: what could it read, what could it change, which plugins were enabled, which credentials were exposed, which sandbox was active, and which release channel was running?

Supported by:

• Codex
• Claude Code
• Gemini CLI
• Pi Coding Agent

Review is moving inside the agent tools

Claude /ultrareview is the cleanest example: provider-native cloud fleets can review branches and PRs. Codex multi-agent controls, Gemini subagent and eval work, and Hermes Curator reports rhyme with it.

This is a useful direction. Agent tools should be able to criticize their own work. But native review is still evidence, not truth.

A review surface can produce a useful claim: "this looks risky," "this path failed," "this patch needs another pass." The project still needs an external standard for what counts as done.

Supported by:

• Claude Code
• Codex
• Gemini CLI
• Hermes Agent

Plugins and skills are becoming the new agent interface

Codex plugins, Claude plugins, Gemini extensions and MCP, Hermes skills, and Pi extension APIs are all part of the same shift. The practical power of an agent is moving into the things around it.

That makes the harness more useful, but also harder to reason about. If a run depends on a plugin, extension, hook, skill, or transport layer, that surface is part of the work environment and should be visible in the record.

Supported by:

• Codex
• Claude Code
• Gemini CLI
• Hermes Agent
• Pi Coding Agent

Do not build your workflow around one agent's current integration list

Pi removed built-in Gemini CLI and Antigravity support while adding many new providers. Gemini's stable, preview, and nightly channels differ materially. Codex alpha and app-server surfaces move quickly.

This is normal frontier motion. The mistake is treating any current integration list as durable architecture.

The stable layer should be the project workflow around the agent: objective, permissions, execution environment, evidence, review, memory, and what the next run should know.

Supported by:

• Pi Coding Agent
• Gemini CLI
• Codex

What Serious Developers Should Do

• Treat persistent goals as useful, but make sure they still match the project-level direction.
• Treat agent-side memory as context, not automatically as the project record.
• Record which goals, recaps, memories, plugins, skills, permission modes, release channels, and transports were active during serious runs.
• Prefer tools that make trust, sandboxing, plugins, sessions, and review state easy to inspect.
• Treat native agent review as evidence, not final judgment.

What Bitter Is Testing

1. How Codex /goal changes long-running work in a real repo.
2. How to record agent memory, permissions, plugins, review output, and release channels without tying Bitter to one tool's vocabulary.
3. Whether Claude /ultrareview, Gemini memory patches, Hermes Curator, and Pi extension metadata produce evidence worth carrying forward.
4. Which agent harnesses expose enough state to be trustworthy over long runs.
5. How to keep the public research loop conservative: no signal unless it can change what someone does next.

What Remains Uncertain

• Whether persistent goals become stable enough for long-horizon development or remain convenience features tied to one tool.
• Whether agent memory surfaces converge, or each product keeps inventing its own private memory layer.
• Whether cloud/native review produces evidence that is inspectable enough for serious work.
• Whether plugin and skill ecosystems converge around useful metadata.
• Which agent tools expose enough permission, session, plugin, transport, and release-channel state to support trustworthy wrapping.