Product Decisions This Supports
- Build vs. buy for agent interoperability. This package is the A2A (Agent-to-Agent) protocol layer — Agent Card discovery, JSON-RPC task exchange, task lifecycle/state. Adopting it lets the team spend roadmap capacity on proprietary agent skills and orchestration logic instead of re-implementing a wire protocol.
- Ecosystem participation strategy. Whether our product exposes agents to third-party orchestrators (discoverability via a published Agent Card, marketplace/registry listings) or only consumes external agents. These are two different roadmap commitments with different security, quota, and SLA requirements — the package supports both directions, so the decision is product-driven, not technical.
- Interop risk hedge. A2A is a vendor-neutral spec. Committing to it reduces exposure to any single agent framework's proprietary protocol, which matters if we expect customers to bring their own agent runtime.
- Internal platform consolidation. Teams already running multiple Laravel services with separate "AI features" can standardize on one agent-to-agent contract rather than N bespoke REST/queue integrations.
- Concrete use cases to scope: cross-team agent delegation inside our own estate; exposing our domain agents (billing, catalog, support triage) as callable skills; brokering to customer-hosted or third-party agents during a workflow; long-running task handoff with streaming progress back to a UI.
When to Consider This Package
Consider it when:
- The stack is PHP/Laravel and we need A2A client and/or server capability without adding a Python or Node service purely for protocol handling.
- We need spec-shaped artifacts — Agent Card publication, JSON-RPC task submission, task status/streaming, artifact return — rather than a generic HTTP wrapper.
- We are still in discovery/prototype on agent interop and want a low-ceremony, Composer-installable starting point.
- We can accept pre-1.0 API churn and want to influence/absorb changes rather than wait for a GA SDK.
Look elsewhere when:
- We need a supported, versioned contract with an SLA or vendor indemnity — this is a single-maintainer beta package.
- The surrounding platform is Python or TypeScript, where the reference/official SDKs and community momentum live; running PHP here adds an unnecessary polyglot hop.
- We need production-hardened concerns out of the box: multi-tenant authn/authz, rate limiting, persistent task stores, horizontal-scale streaming, observability.
- Our requirements outrun the spec subset implemented — check streaming/SSE, push notifications, and extended agent card fields against our roadmap before committing.
- We cannot tolerate a breaking change mid-quarter; a
0.9.x line implies the public API may still move before 1.0.
On this specific release (v0.9.6-beta): the changelog is dependency maintenance only — no new features, no deprecations, no documented breaking changes to the package's own API. Notable internals: Guzzle has moved onto the 8.x line and ramsey/uuid, monolog, and static-analysis tooling were refreshed. Two practical actions: pin guzzlehttp/guzzle and PHP constraints in our composer.json before upgrading, and treat the accumulated Guzzle major-version movement as a signal to re-run our integration tests against our own HTTP middleware stack rather than trusting a green dependabot merge.
How to Pitch It (Stakeholders)
For executives (one paragraph): Agent-to-agent communication is converging on a shared open protocol, the same way HTTP and OAuth did. This package is a small, low-cost way for us to be a first-class participant in that ecosystem from our existing PHP platform — publishing our agents for others to call, and calling theirs — without a new service, new language, or bespoke integration per partner. The cost of adoption is measured in days, not a quarter, and the strategic value is optionality: we can enter agent marketplaces and customer orchestrations without re-platforming. The risk is maturity, not fit — the package is beta with a single maintainer, so we should pilot it behind our own abstraction layer rather than making it load-bearing.
For engineering (summary): PSR/Composer-friendly Laravel package implementing A2A — agent card exposure, JSON-RPC task calls, task state and streaming. Adopt behind a thin internal interface (AgentGateway) so the protocol library is swappable. Expect pre-1.0 churn; pin Guzzle and PHP constraints, and validate upgrades against our own HTTP client and middleware configuration. Add the usual production guardrails ourselves: auth between agents, request quotas, durable task persistence, and tracing across delegated tasks — the package is a protocol implementation, not an operations story.