Vizra Adk Laravel Package

Product Decisions This Supports

• Build vs. buy for agent orchestration. This package is a buy (well, adopt-open-source) answer to a build question: do we hand-roll agent loops, tool-calling, conversation state, streaming, and tracing on top of a raw LLM SDK, or take an opinionated Laravel-native layer? Vizra ADK covers the full scaffold — BaseLlmAgent subclasses, ToolInterface tools, sub-agent delegation, persistent memory, sequential/parallel/conditional workflows, five execution modes (conversational, scheduled, webhook, event-driven, queued), SSE streaming, execution traces, and a Livewire dashboard. Adopting it is roughly a "weeks not months" decision for the orchestration layer.
• Scope containment on the first AI feature. The package absorbs the undifferentiated plumbing (state manager, message persistence, provider abstraction via Prism, MCP client management) so the PM can keep the roadmap argument focused on the actual product surface — which tools, which workflows, which users — rather than on infrastructure the team would otherwise rebuild.
• Multi-provider commitment (or deliberate non-commitment). Because it wraps Prism with OpenAI/Anthropic/Gemini support, this supports a roadmap decision to not hard-wire to one model vendor, and to defer the "which provider is strategic" call until there's evaluation data. It also means per-feature model choice can be a config decision, not an architecture decision.
• Multi-tenancy and per-customer configuration. Changelog entries for dynamic agent name resolution (team_agent_24), lightweight withUserContext(array), and per-tenant MCP config overrides signal that the package anticipated B2B/SaaS agent deployments. If the roadmap includes per-customer agents or per-tenant API keys for tool servers, this materially reduces the design work.
• Evaluation as a first-class roadmap item. The bundled eval framework with LLM-as-a-Judge, plus the successor project vizra/evals, supports a decision to budget for agent quality measurement before scaling usage — regression detection, CI evaluation runs, quality metrics. PMs should treat this as the artifact that lets them make claims about agent quality instead of anecdotes.
• A time-boxed prototyping decision. The strongest legitimate use: a 4–8 week spike to prove an agent workflow, with a pre-agreed exit. The package gets a demo into stakeholders' hands fast; the decision it informs is "is this workflow worth building properly on the official Laravel AI SDK?"
• Roadmap constraint to record explicitly: this is a retired package. v0.0.48 is final; no bug fixes, no security patches, no monitored issues, prism-php/prism pinned at ^0.99.20, no migration path to the successor (vizra/evals is an evaluation tool, not an agent builder). Any roadmap that depends on it carries a standing "fork and maintain, or replace" line item that must be on the plan, not in the risk appendix.

When to Consider This Package

Consider adoption when:

• The stack is already Laravel 11–13 / PHP 8.2+ with MySQL or PostgreSQL, and the team writes idiomatic Laravel (Artisan, Eloquent, service providers, Livewire). The developer-experience fit is the main reason to pick this over a framework-agnostic agent library.
• You are building an internal tool, prototype, demo, or proof-of-concept with a lifespan measured in weeks or a single quarter — where a retired dependency is an accepted, documented trade.
• You need a working feature surface now and are willing to pin "vizra/vizra-adk": "0.0.48" and freeze the surrounding dependency graph.
• Your team has PHP depth and appetite to fork. MIT-licensed, forking is explicitly sanctioned by the maintainers, and the fork can be vendored internally. Budget it as real engineering time — not a one-off.
• You want the whole bundle — agents + tools + memory + workflows + streaming + tracing + dashboard + evals. Adopting it for one narrow slice (say, just streaming) is a poor trade given the maintenance overhead.
• Existing lock-in already exists: if a codebase or team skill set is already built on it, continue with a pinned version and a written deprecation/exit plan rather than a rushed migration.

Look elsewhere when:

• The feature is a production, customer-facing, multi-year commitment with security, compliance, or SLA expectations. No security patches is a hard stop for anything handling regulated or sensitive data.
• You need vendor support, escalation paths, or guaranteed compatibility with future Laravel/PHP releases. Dependencies will "age out from under it" — that's the maintainer's own phrasing.
• You're planning long-lived agent infrastructure. Go directly to the official Laravel AI SDK, which is the foundation Vizra itself now builds on, and pair it with vizra/evals for testing. Skipping the intermediate hop avoids a migration you'd have to do anyway.
• You need cutting-edge model support or rapid iteration on new provider capabilities; a pinned Prism version will lag.
• The team is not PHP-native or would need to learn Laravel patterns and absorb an unmaintained dependency — two risks stacked.
• You need scale-out evaluation and trace analytics as a product capability. The "Vizra Cloud" platform referenced in the README was never shipped; the eval framework is local/self-hosted, and the commercial layer is gone.

How to Pitch It (Stakeholders)

One-line summary for executives: An open-source, MIT-licensed Laravel toolkit that would let us stand up a working AI agent — with tools, memory, streaming, and tracing — in weeks instead of months. It is also officially retired, so we should treat it as a short-term accelerator with a planned exit, not a platform bet.

For engineering: Idiomatic Laravel throughout — Artisan generators, Eloquent-backed state, macros for extension, a Livewire dashboard for manual testing, and a trace view for debugging. Prism underneath gives us provider portability. Concrete ask: pin 0.0.48, lock the dependency graph, and decide up front whether we fork or plan a replacement on the official Laravel AI SDK.

Framing the risk honestly — this is the pitch's core:

• It works, and it's free. Nothing has been taken down; Packagist keeps serving it. The feature set is genuinely broad and the v0.0.x changelog shows real hardening (incremental message persistence, SSE parsing for MCP servers, multi-tenant config isolation, streaming fixes).
• But it is frozen. No bug fixes, no security patches, unmonitored issues, pinned Prism version, untested on future Laravel releases. Mitigation is a fork we control, and that fork is headcount, not a footnote.
• The successor isn't a replacement. vizra/evals tests agents; it doesn't build them. The stated forward path for building is the official Laravel AI SDK. There is no migration bridge, so our exit is a rewrite of the agent layer — bounded, but real.
• The score is misleading. High qualitative score, near-zero adoption signal — no dependents, no ecosystem, no third parties to lean on for answers. Novelty, not validation.

Recommendation to put in front of the room: Approve as a time-boxed internal build — one quarter, one workflow, one team — with three conditions agreed before kickoff: (1) version pinned and dependency graph frozen; (2) a fork-or-replace decision scheduled at the end of the time box, with the fork cost estimated in engineer-weeks; (3) no customer-facing or regulated-data use without a security review that accounts for the absence of upstream patches. If the team cannot commit to conditions 1–3, skip this and build on the official Laravel AI SDK directly — the time saved up front is smaller than the cost of an unplanned exit later.