Laravel Ai Orbit Laravel Package

Product Decisions This Supports

• Build vs. buy for the AI integration layer. The core PM question this package answers is whether to hand-roll provider abstraction (client wrappers, retries, token accounting, streaming, prompt/response logging) or adopt an existing Laravel-native package. An orbit-style orchestration layer is typically the "buy/adopt" side of that trade — it moves weeks of plumbing off your roadmap.
• Multi-provider strategy and lock-in posture. If the package abstracts across LLM providers, it directly supports the roadmap decision of whether to ship on one vendor or keep a portable abstraction. That decision affects pricing exposure, failover design, and how expensive it is to re-platform later.
• Roadmap sequencing for AI features. Whether AI capability ships as chat, summarization, embeddings/search, or agentic workflows depends heavily on what the underlying layer makes cheap. A mature orchestration package makes "add a second AI feature" incremental; a thin one makes each feature a new integration project.
• Cost and reliability guardrails as a product requirement. Provider fallback, rate-limit handling, and usage observability are product-visible concerns (uptime of AI features, unit economics per user). This package is the natural home for those decisions rather than scattering them across feature code.
• Upgrade and versioning posture — newly relevant. v2.0.0 is a major bump from v1.3.2, which by convention signals breaking changes. That converts an evaluation question into a planning question: if we adopt, we commit to a dependency that has already demonstrated one breaking major release, so we should budget for migration work and pin versions deliberately.

When to Consider This Package

Consider it when:

• The product is already a Laravel/PHP application — the value is in framework-native ergonomics (config, service container, queued jobs, facades) that don't transfer to other stacks.
• You need a provider-agnostic seam rather than a single-vendor SDK, and you expect to swap or add models/providers within 12 months.
• The team is small and would rather not own retry logic, streaming plumbing, and usage tracking as internal infrastructure.
• AI is adjacent to the core product (an assistant, enrichment, summarization) rather than the entire business — i.e., a dependency is acceptable where a platform would be overkill.
• You can tolerate community-maintained release cadence and are willing to pin versions and test upgrades.

Look elsewhere when:

• You need commercial SLAs, security review artifacts, or vendor indemnity — a community package rarely clears enterprise procurement without a maintained fork or internal ownership plan.
• Your workflows are deeply agentic or stateful (long-running orchestration, complex tool graphs); a general abstraction may add indirection without covering the hard parts.
• You are already on v1.x in production — treat v2.0.0 as a migration project, not a version bump, until the changelog is actually read.
• The stack is not Laravel, or the team is standardizing on official provider SDKs to minimize third-party surface area.
• Maintenance signals are weak (release cadence, issue responsiveness, test coverage, PHP/Laravel version support). A major bump after a long gap is a prompt to check this, not evidence against it.

Caveat on this specific release: the v2.0.0 notes are only a compare link with no described changes. Before any adoption or upgrade decision, engineering should diff v1.3.2...v2.0.0 and confirm: breaking API changes, minimum PHP/Laravel versions, config file changes, and any removed providers or drivers. PM should not commit roadmap dates to this dependency until that review lands.

How to Pitch It (Stakeholders)

For executives: This is a Laravel-native AI integration layer — it lets us add AI features without building and maintaining the provider plumbing ourselves, and without hard-wiring the product to one AI vendor. The strategic value is optionality: we keep the ability to switch providers on cost or performance grounds rather than being re-platformed by a price change. The cost is a third-party dependency with a community release cadence, and a just-shipped major version that implies a breaking-change migration at some point. Recommendation: evaluate, don't commit — a short technical spike to diff v1.3.2 → v2.0.0 and confirm maintenance health, then a decision with a pinned version and a named internal owner.

For engineering: Treat v2.0.0 as uncharacterized. The release notes are a changelog link only, so the first task is a concrete diff review: public API surface, config schema, Laravel/PHP version floor, dropped drivers, and test coverage on the new major. If we adopt, pin exactly, wrap it behind our own thin interface so a future swap or fork is a contained change, and avoid leaking package-specific types into domain code. If we're already on 1.x, scope the upgrade as its own ticket with a rollback path rather than folding it into feature work.

Decision requested: approval for a time-boxed evaluation spike, with adoption contingent on the diff review and maintenance-health check.