Skip to content

Releases: Tsubasa-Kaede/runtime-neutral-agent-engineering

v2.3.0 — Remote Collaboration

Choose a tag to compare

@Tsubasa-Kaede Tsubasa-Kaede released this 07 Sep 18:27

Remote Collaboration

dual-agent-development 2.3.0 introduces the first production release of
cross-process Remote Collaboration.

Two agent runtimes can now collaborate through a packet-based,
runtime-neutral boundary without coupling the collaboration protocol
to a specific agent provider.

What you can do

  • Connect two agent runtimes across a real process boundary.
  • Exchange typed collaboration packets through a runtime-neutral envelope.
  • Preserve task and correlation identity across the remote boundary.
  • Use a composition root to construct remote sessions from agent declarations.
  • Run a real Claude Code collaboration example.
  • Keep local and remote execution concerns separated from transport.

Quick start

The repository contains two focused examples:

  • examples/remote_offline_demo.py — deterministic offline demonstration.
  • examples/remote_real_claude.py — REAL Claude Code collaboration.

The examples are repository examples and are intentionally not part of the
installed Python package.

Offline vs REAL

The offline example uses a deterministic scripted agent and requires no
provider credentials.

The REAL Claude example invokes the local Claude Code CLI and therefore
requires Claude Code to be installed and authenticated.

A missing REAL prerequisite fails explicitly; it never silently falls back
to the offline implementation.

Architecture

The remote collaboration path is intentionally layered:

Agent declaration → Remote composition (build_remote_session) →
RemoteAgentSession → subprocess stdio envelope transport →
child-process endpoint → agent adapter

Transport, session, endpoint, and runtime execution remain separate
responsibilities.

Current boundary

2.3.0 provides cross-process remote collaboration.

It does not provide:

  • cross-machine networking
  • agent authentication or authorization
  • cancellation semantics
  • retry/reconnect
  • global capability-based agent selection
  • distributed multi-agent scheduling
  • agent network / marketplace
  • dashboard or hosted service

Those are intentionally outside this release.

Installation

pip install dual-agent-development==2.3.0

Python 3.10+ is supported.

Documentation

See the README for the Remote Collaboration quick start, architecture,
examples, and common failure guidance.

2.2.0 — qualify / run product entry and persisted evidence

Choose a tag to compare

@Tsubasa-Kaede Tsubasa-Kaede released this 06 Sep 05:27

2.2.0 is the first installable product release: the installed CLI is now a
self-contained product entry with persisted qualification evidence.

Highlights

  • dual-agent qualify — explicit gated G1–G14 qualification; persists VERIFIED + REAL evidence under ~/.dual-agent/qualification/ (REAL invocation requires RUN_REAL_PROVIDER_TESTS=1)
  • dual-agent run — reads persisted evidence only and never auto-qualifies; no evidence exits 2 with a machine-readable reason and a human hint
  • dual-agent run --observe — execution observation streamed to stderr while stdout stays exactly one machine-readable JSON line
  • Stable CLI semantics — exit codes (SUCCESS → 0, closed failure words → 2), stdout machine JSON / stderr human diagnostics
  • python -m dual_agent — module entry alongside the console script
  • Packaging — dynamic single-truth version, product-only sdist/wheel, offline packaging smoke (build → isolated venv install)

Install

pip install dual-agent-development==2.2.0

dual-agent --version   # dual-agent 2.2.0
dual-agent --help      # product surface: qualify / run / --observe

First use:

dual-agent qualify
dual-agent run "refactor the parser module"

Runtime support

  • REAL VERIFIED (gated qualification proven end to end): Claude Code, Codex CLI, Pi
  • Adapter implemented (REAL qualification runs on machines where the CLI is installed): Gemini CLI, Qwen Code, OpenCode, Cline, tiny-agents

Verification

  • Full offline suite green: 2176 tests / 24 skips / 520 subtests
  • PyPI artifacts verified in a clean venv installed from the public index: console script and python -m dual_agent both report dual-agent 2.2.0

Attached below are the same sdist and wheel that are published on PyPI.

Runtime-Neutral Agent Engineering v2.1.0

Choose a tag to compare

@Tsubasa-Kaede Tsubasa-Kaede released this 27 Aug 22:18

v2.1.0 — Minor Release

New adapter capability, no breaking changes. Compared to v2.0.0: 12 commits, 19 files changed (+2205 / −401), exactly one production feature addition.

New: Codex CLI adapter

  • Adds dual_agent.codex_adapter implementing the runtime adapter contract for the Codex CLI (Level B: adapter implemented, discovery + integration tested; not REAL-verified).
  • Covered by tests/test_codex_adapter.py and tests/test_codex_integration.py.

Collaboration & tooling

  • Collaboration transport end-to-end coverage: tests/test_collaboration_transport_e2e.py.
  • Onboarding bootstrap utility: scripts/bootstrap.py (with tests/test_bootstrap.py).
  • New example: examples/minimal_host_app.py, a minimal host application for the facade (with tests).
  • Test-only fix: REAL dual-agent smoke timeout aligned with the production default.

Documentation & community

  • Added CONTRIBUTING.md and SECURITY.md.
  • README finalized: integration status (REAL VERIFIED / Adapter implemented), runtime configuration, and responsibility boundary.
  • Clone URL and installation docs updated for the renamed repository.

Packaging & release engineering

  • Version 2.1.0 published to PyPI via Trusted Publishing / OIDC (no API tokens, no stored credentials).
  • Production publish workflow (tag-triggered, environment-gated) and an isolated TestPyPI drill workflow (workflow_dispatch only) added; the TestPyPI drill was executed and verified end-to-end before this release.

Install

Distribution dual-agent-development (import dual_agent), Python >= 3.10, zero runtime dependencies.

pip install dual-agent-development==2.1.0

https://pypi.org/project/dual-agent-development/2.1.0/

Checksums (from formal PyPI 2.1.0 release metadata):

  • dual_agent_development-2.1.0-py3-none-any.whl sha256 e760aa690e667ff5f7c22692ddfe43edfec075a9643c169b93c1d329edbef432
  • dual_agent_development-2.1.0.tar.gz sha256 620a69420cc64f192d1c11e1e88fd970923a3df973f9bbe5ac9d60c3973a7806

Verification

  • CI / offline test baseline: 979 passed / 15 skipped / 377 subtests (measured on the release commit).
  • REAL runtime smoke (Claude Code) remains opt-in via RUN_REAL_PROVIDER_TESTS=1 and stays closed in CI.

Runtime-Neutral Agent Engineering v2.0.0

Choose a tag to compare

@Tsubasa-Kaede Tsubasa-Kaede released this 25 Aug 18:49
4e8c971

Runtime-Neutral Agent Engineering v2.0.0

Overview

V2 establishes a runtime-neutral engineering foundation for agent execution.

This release focuses on making agent runtime usage discoverable, verifiable, and controllable without coupling the engineering layer to a specific runtime.

Core capabilities

  • Runtime discovery and health assessment
  • Capability validation and qualification
  • Real-runtime verification
  • Verified Runtime admission
  • Controlled execution
  • Runtime-neutral adapter contracts
  • Structured agent collaboration packets
  • Execution provenance and safety boundaries

Verification

  • 945 tests passed
  • 21 tests skipped
  • 377 subtests
  • CI verified on the release branch
  • REAL runtime verification evidence included for Claude Code

Collaboration

V2 establishes the protocol foundation for structured agent collaboration.

Remote transport, distributed collaboration, and full multi-agent network capabilities remain outside the scope of this release and are planned for future development.

V2 → V3

V2 provides the runtime engineering foundation.

Future V3 work may extend this foundation toward:

  • Agent identity
  • Agent discovery
  • Trust
  • Remote collaboration
  • Multi-agent orchestration

These capabilities are not part of v2.0.0.

Documentation

See the README and development documentation for architecture, verification boundaries, safety constraints, and implementation details.