Vizra Adk Laravel Package

Technical Evaluation

Architecture fit. Vizra ADK is a Laravel-native agent framework, and its shape is unusually well matched to a conventional Laravel monolith or modular monolith. Agents are plain classes extending BaseLlmAgent with declarative $name, $instructions, $model, $tools, and $maxSteps properties; they are auto-discovered rather than registered. Tools implement a ToolInterface with a JSON-Schema definition() and an execute(array $arguments, AgentContext $context) method, which means tool logic lives exactly where a Laravel engineer would expect it — next to Eloquent models, policies, and jobs. State lives in MySQL/Postgres via published migrations, so memory, traces, and sessions are queryable with existing tooling rather than trapped in a vector store. Workflows (sequential, parallel, conditional, loops), multiple execution modes (conversational, scheduled, webhook, event-driven, queue), SSE streaming, sub-agent delegation, MCP client support, and a Livewire 4 dashboard round it out. The macro system on AgentBuilder and the withUserContext(array) escape hatch show the author understood Laravel extension idioms. Architecturally, this is a good fit for a team already on Laravel 11+.

Integration feasibility. Mechanically trivial: composer require, php artisan vizra:install (config + migrations), php artisan vizra:make:agent, and a first agent is running in under an hour. The README's "That's it! No registration needed" is genuine — auto-discovery removes a whole class of wiring work. Multi-tenant concerns are addressed (dynamic agent name resolution, per-tenant MCP config overrides via AgentContext, non-singleton MCPClientManager binding for isolation), which is the right set of problems for a SaaS product to have already solved. Feasibility is high in the technical sense and near-zero in the institutional sense: the package is retired as of August 2026, v0.0.48 is the final release, and issues and PRs are unmonitored.

Technical risk. This is the dominant factor and it is not close. Key risks, roughly ordered:

1. Abandonment with no successor. The maintainers explicitly state there is no migration path to their replacement, vizra/evals — that project tests agents built on the official Laravel AI SDK, it does not build them. So there is no vendor-blessed off-ramp; the only off-ramps are the official Laravel AI SDK (a rewrite of the agent layer) or a fork (an ownership commitment).
2. Dependency stranglehold. prism-php/prism is pinned at ^0.99.20. Prism is the layer that talks to OpenAI, Anthropic, and Gemini. Any new provider model, API version change, or streaming protocol change lands upstream in Prism and does not reach us without forking. This is the most likely first production break, and it is a silent break — the package keeps installing fine while the providers move on underneath it.
3. Laravel 13 is the tested ceiling. Laravel 11, 12, and 13 are claimed; anything after is untested and unsupported. Every future Laravel upgrade becomes an unassisted migration of a package we do not control.
4. No security patches. Zero. A CVE in this package's code, or in a transitive dependency it pins, is ours to find and fix.
5. Adoption signal is absent. dependents: 0 and blank stars mean there is no downstream ecosystem pressure to produce a community fork. The "Score: 9.9" appears to be a relevance/quality score from an automated evaluation, not evidence of adoption — the opportunity: 49.74 figure and zero dependents should be read as the real health indicators. If we fork, we are likely forking alone.
6. Hard requirements that may not match our stack. livewire ^4.0 is required for the dashboard; if the host application is on Livewire 3, the dashboard is unavailable or the install conflicts. MySQL/Postgres is required — SQLite-based local and CI environments may not exercise the same code paths. At least one LLM provider key is mandatory to do anything meaningful, which complicates CI.
7. Prompt-injection blast radius. Tools execute arbitrary application code with database access. An agent that can be steered by untrusted input into calling RefundProcessorTool or OrderLookupTool with attacker-chosen arguments is a business-logic vulnerability, not just an AI quirk. This risk exists with any framework but is amplified here because there is no upstream to publish hardening guidance or patches.

Key questions.

• What is the actual date relative to the August 2026 retirement, and is the EOL already past or approaching? This determines whether "pin and carry on" is a two-quarter bridge or a permanent ownership decision.
• Are we adopting this to ship agents or to learn what agents should look like in our product? The answer flips the recommendation entirely.
• Which Laravel and Livewire versions is the target application on today, and what is the upgrade cadence? A team that upgrades Laravel annually is signing up for an annual unassisted migration.
• Do we have a security review gate that will accept a dependency with zero patch cadence? Most enterprise programs will not, and that is the correct answer.
• Is there budget for one engineer to own an internal fork — dependency bumps, Prism upgrades, CVE response — indefinitely? If not, this is a prototype-only dependency.
• What does a rewrite onto the official Laravel AI SDK actually cost? Until that number is estimated, we cannot evaluate the fork option rationally.
• Do we need agent evaluation (LLM-as-judge, regression detection) as a first-class capability? If so, vizra/evals is worth evaluating on its own merits regardless of what we do about the ADK.

Integration Approach

Stack fit. Requirements are PHP 8.2+, Laravel 11.0+, MySQL or PostgreSQL, Livewire ^4.0 for the dashboard, and at least one of OpenAI / Anthropic / Google via Prism. This fits a standard Laravel SaaS backend cleanly. It does not fit a Laravel app pinned to Livewire 3, an app on SQLite beyond local prototyping, or a polyglot stack where the agent layer needs to be callable from non-PHP services (nothing here suggests a language-agnostic SDK). The package is best positioned as the agent-orchestration layer inside the Laravel app, invoked from HTTP controllers, queued jobs, scheduled commands, and webhooks — not as a standalone service.

Migration path. There are exactly two, and they should be chosen explicitly rather than drifted into.

Path A — Adopt and own. Pin "vizra/vizra-adk": "0.0.48" exactly, fork to an internal namespace, and treat the fork as a first-class internal library with CI, an owner, and a documented Prism bump procedure. This preserves the package's real strengths (workflow primitives, tool contract, memory model, MCP support, dashboard) at the cost of permanent maintenance. Justified only if we need agent capability faster than we could build it on the official SDK, or if the workflow/tool abstractions are a genuine fit we would otherwise reimplement badly.

Path B — Skip to the official Laravel AI SDK. Recommended default for anything greenfield or net-new. The ADK's own maintainers point here for building agents, which is the strongest possible endorsement of the direction. Costs a rewrite of the agent layer conceptually, but there is nothing to migrate — we simply never accrue the debt.

A middle position worth naming: prototype on the ADK, ship on the SDK. Use the ADK to explore workflow shapes, tool schemas, and prompt designs cheaply, then implement the production version against the SDK. This works only if the prototype does not leak into production code and if the agent boundary is thin.

Compatibility. The binding constraints are the Prism pin (^0.99.20) and the untested status of Laravel beyond 13. Livewire ^4.0 is a hard requirement for the dashboard component only — the agent runtime itself is usable without it, which is worth verifying before it becomes a blocker. MySQL/Postgres is required for the migration set and the enlarged agent_messages.content column. In practice: pin every transitive dependency, commit the lockfile, and add a scheduled job or Renovate rule that notifies rather than auto-merges anything in the Prism subtree.

Sequencing. Four phases, with an explicit kill gate.

1. Spike (1–2 weeks, one engineer). Sandbox Laravel install, vizra:install, one agent, two tools against a read-only replica, one workflow with a conditional branch, streaming exercised through the Livewire dashboard. Success criteria: end-to-end latency, token cost per interaction, and whether the abstraction fits our domain model.
2. Decision gate (1 week, TPM + security + platform lead). Inputs: spike results, a security sign-off attempt on a zero-patch dependency, a written estimate for Path B, and a written estimate for owning the fork. Output: a named path, in writing. Do not let this gate be skipped or softened into "we'll decide later" — drift into Path A by default is the failure mode.
3. If Path A — harden. Fork, rename, add CI (unit + integration against a real provider key in a gated environment), document the Prism bump procedure, and wrap the runtime behind an internal AgentRunner interface with two methods (run(agent, input, context): AgentResult). That interface is the insurance policy; if the fork becomes untenable, swapping to the SDK becomes a single adapter change rather than a codebase-wide rewrite. Also sandbox tool execution: authorization checks inside each tool, never inherited from the calling context.
4. If Path B — implement directly. Build against the official Laravel AI SDK, and evaluate vizra/evals separately if automated agent quality testing is on the roadmap — the evaluation concern is orthogonal and survives whichever runtime we choose.

Operational Impact

Maintenance. This is the crux. Post-August 2026, all bug fixes, security patches, dependency upgrades, and compatibility work become ours. The package's own changelog shows a steady stream of exactly the kind of small, necessary fixes that stop happening: incremental message persistence in 0.0.24, SSE parsing for MCP servers and a column-size increase in 0.0.35, per-tenant config isolation in 0.0.37, image/document serialization filtering and session-association fix in 0.0.38. Each of those was somebody's production bug. We inherit the class, not the fix. Budget realistically: a fork with active dependency work is fractional headcount, and that estimate should be on the table before the adoption decision, not after.

Support. There is no support. Discord and GitHub are explicitly unmonitored; the vizra.ai/docs site may persist or may rot, and the Cloud platform advertised in the README ("Coming Soon!") should be treated as vapor given the retirement. Knowledge is frozen at v0.0.48. The practical consequence is a bus-factor mitigation requirement: internal runbook, internal architecture notes, and at least two engineers who understand the tool-execution loop and the memory model. The included skills/vizra-agent-creation SKILL.md is a genuine accelerator for AI-assisted coding on day one — but it documents a snapshot, and it will not update either.

Scaling. Three distinct pressure points. First, cost — every agent turn is tokens, maxSteps defaults to 5 so a tool-heavy agent can multiply spend per request in ways that don't show up in a latency dashboard; token accounting per user/tenant (the macro example tracks a model for exactly this) is not optional. Second, database — memory, messages, and traces are all Eloquent rows; agent_messages content was explicitly widened for large MCP payloads, which is a signal that this table grows fast and wide. Trace and message tables need a retention policy and archival path designed in, not bolted on. Third, concurrency — scheduled, webhook, and event-driven execution modes plus parallel workflows will flood the queue if not rate-limited and separated onto a dedicated queue with its own worker pool and concurrency caps; a runaway agent loop sharing a queue with order-processing jobs is an outage, not a slowdown. The multi-tenant overrides added in 0.0.37 and the non-singleton MCPClientManager binding suggest the isolation boundary was considered, but isolation correctness under concurrency should be explicitly tested, not assumed.

Failure modes. In rough order of likelihood:

• Provider drift. Prism's pinned version stops supporting a new model or API version we want, or a provider deprecates an API Prism 0.99.x speaks. Symptom is a hard failure with no upstream fix; remedy is a fork patch, which requires we did the fork.
• Framework drift. A Laravel or Livewire upgrade breaks the package. Symptom is a blocked framework upgrade — the package becomes the reason we cannot take a security patch elsewhere, which is the worst version of this problem.
• Quiet dependency aging. No error at all; just a package that stops working against modern providers and a team that discovers this during an incident. This is the most insidious because nothing triggers a review.
• Prompt-injection-driven tool abuse. Untrusted input steers an agent into calling a write-capable tool with attacker-chosen arguments. Mitigation is per-tool authorization and a hard split between read-only and mutating tools, with mutating tools requiring human confirmation.
• Runaway loops and cost spikes. maxSteps exceeded or a tool returning unusable output causing repeated retries. Mitigation is per-tenant budget ceilings, circuit breakers, and alerting on tokens-per-request outliers.
• Table growth. Messages and traces degrade query performance and backup/replication times. Mitigation is retention policy plus indexes defined by us, since no upstream will add them.
• Silent dashboard breakage. Livewire 4 coupling means the monitoring UI dies before the runtime does — a debugging capability loss that arrives when we need it most.

Ramp-up. Developer productivity is genuinely high on day one: Laravel engineers will recognize every pattern, vizra:make:agent scaffolds the shape, auto-discovery means no registration ceremony, and the SKILL.md gives AI coding assistants the exact conventions. A competent Laravel engineer ships a working tool-using agent in a day. The ramp-up risk is not the first week — it is month six, when the docs have frozen, the community has dispersed, and every question ("why does this tool call stall?", "why did streaming break?") has exactly one answerer: us. Ramp-up planning should therefore front-load the operational knowledge (runbook, escalation path, fork build process, provider-upgrade drill) rather than the framework API, which developers will absorb on their own.

Bottom line for the TPM. The package is a well-built solution to a real problem, shipped by someone who has now moved on. For a time-boxed prototype or an internal tool with low blast radius, pin 0.0.48, isolate it behind an interface, and accept the debt knowingly. For anything customer-facing with a security review gate, the correct call is to build on the official Laravel AI SDK and treat this package as a design reference rather than a dependency — the maintainers, to their credit, say the same thing.