Product Decisions This Supports
- Feature scoping and estimation for "AI feature" PRDs. The package collapses the three enablers most agentic features need — tool/function calling, structured output, and per-user conversation memory — into configuration on an
Agent class. That lets you size an AI feature in days (define agent, tools, history) instead of weeks of bespoke prompt plumbing, and keeps prompt/agent logic in version-controlled code rather than scattered in a vendor dashboard.
- Build vs. buy vs. assemble. This is the "assemble" option: an MIT-licensed framework over provider SDKs, not a hosted agent platform. You keep ownership of prompts, tools, and data location, and you avoid per-seat or per-run platform fees. That's a direct input to gross-margin and lock-in analysis versus an OpenAI Assistants-style hosted offering.
- Roadmap sequencing. The feature set maps cleanly onto a phased AI roadmap: (1) single-agent chat with per-user history, (2) tools and actions on internal systems, (3) multi-agent workflows with queues and chainable tasks, (4) exposing agents through an OpenAI-compatible API so existing clients, prototypes, or partner integrations can consume them without new frontend work. Each phase is additive, which means you can ship value and re-decide at each gate.
- Availability and cost posture as a config decision, not an architecture decision. Multi-provider fallback (
protected $provider = ['default', 'gemini', 'claude']) with per-provider overrides means provider failover, cost arbitrage, and regional-provider requirements can be trialed without a re-architecture. Useful when an exec asks "what happens if OpenAI is down / repriced?"
- Observability and guardrails planning. The event system hooks nearly every step, including before/after tool execution. That's the substrate for the metrics leadership will ask for — tool-call counts, per-conversation latency, cost attribution, and audit trails for actions an agent takes on real systems.
- Privacy, retention, and data-residency commitments. Pluggable chat history (in-memory, cache, JSON, custom) plus per-user scoping (
::forUser(...)) or custom history keys lets you choose where conversation data lives to match your DPA, deletion-on-request, and retention stance — rather than inheriting a vendor's.
- Reversibility as a strategic hedge. Standard Laravel patterns, config-driven providers, and MIT licensing keep exit cost bounded. That justifies running a cheap PoC now rather than a multi-quarter platform commitment.
When to Consider This Package
Consider it when:
- You ship a Laravel 10+/PHP 8.3+ application where AI is a feature (support triage, internal ops automation, document extraction, data-entry copilots, workflow triggers), not the whole product.
- The team is Laravel-fluent and you want to avoid introducing a Python service and a second runtime into the stack.
- You need tools, memory, structured output, and streaming quickly, and you're willing to own prompt quality and evaluation yourself.
- You require control over where conversation data is stored, or you have data-residency/retention obligations that a hosted agent vendor complicates.
- You want to prototype multi-provider behavior (failover, cost, quality comparisons) before committing to one model vendor.
Look elsewhere when:
- The AI capability is business-critical, high-volume, or core to revenue. Signal is thin: ~645 stars and zero dependents means almost no public production validation. For a load-bearing AI core, a first-party SDK or a vendor platform with support terms is the safer default until adoption evidence improves.
- You need long-term API stability across many squads. The v0.7 → v0.8 changelog documents breaking changes to event and hook signatures in a minor release. That's normal for pre-1.0 OSS, but it means version pinning plus budgeted migration work — awkward for a platform team serving multiple internal consumers.
- You need capabilities the package doesn't claim to provide. RAG/vector retrieval, evaluation harnesses, prompt versioning/experimentation, and cost dashboards are not in the feature list. You'll bring those yourself or pair it with other tooling.
- You're in a regulated or SLA-bound environment. Support is community-based (GitHub, Discord); no commercial SLA or LTS policy is described.
- You need heavy orchestration/governance at scale, or a polyglot stack. The abstraction is Laravel-shaped; non-Laravel services can't share it.
- The requirement is genuinely a single completion call. Reach for the raw provider SDK; a framework is overhead.
How to Pitch It (Stakeholders)
For executives: LarAgent is the Laravel-native way to build AI agents — the "Eloquent model" experience applied to agents, tools, and memory. It shortens time-to-first-working-demo substantially, is MIT-licensed with no platform fees, and is backed by Redberry, a Diamond-tier Laravel partner, which reduces abandonment risk compared to a random OSS dependency. The honest risk read is maturity: it's early-major-version, changes break APIs between minors, and it has one dominant maintainer with no visible downstream dependents. The mitigations are cheap: pin the version, keep our agents behind a thin internal interface, and treat this as a two-to-three sprint PoC with a defined go/no-go — not a platform bet. Recommended decision: approve the PoC, defer the "core dependency" decision until we see adoption and a stable release line.
For engineering: php artisan make:agent scaffolds an Agent class with model, provider, temperature, history driver, and tools as declared properties; tools are attribute-annotated methods or classes, with parallel tool execution (disable-able). History drivers are pluggable and per-user. Multi-provider failover is configuration. Everything is hookable via events, including tool-call-level before/after with the ToolCall object for audit logging. Requires PHP 8.3+, supports Laravel 10–13, and works standalone. The asks in exchange for adoption: pin the version, wrap agents behind our own interface, log tool calls and token/cost metrics from day one, and write tests against a fake driver so provider changes don't leak into our test suite.