Laravel's first-party AI SDK unifies providers, agents and tools for PHP developers

Laravel ships a first-party AI SDK

Laravel developers now have an official package, laravel/ai, built for adding AI features to PHP applications without hand-rolling HTTP calls to every model vendor. According to a getting-started tutorial published on dev.to, the package offers a single, consistent place to configure providers, define agents, call models, use tools, request structured output and keep tabs on usage.

The tutorial's central point is one of positioning: the SDK is an integration layer, not a feature in itself. The surrounding Laravel application continues to own the use case — authorization, validation, persistence, queues, logging and user experience — while the SDK supplies a Laravel-native bridge to AI providers.

What the package covers

Before this package existed, Laravel apps typically wired up AI using raw HTTP clients, vendor SDKs or small wrapper services, which works for a prototype but gets unwieldy once a product needs multiple providers, conversation context, structured output, tools, streaming, cost tracking, testing and failover.

The dev.to walkthrough lists the SDK's building blocks:

• Provider abstraction that covers OpenAI, Anthropic, Gemini, Groq, Mistral, DeepSeek, xAI, Ollama, Azure OpenAI, OpenRouter and OpenAI-compatible endpoints through one consistent API.
• Agents: PHP classes that bundle instructions, context, tools, model configuration and an optional output schema.
• Structured, schema-based output for cases where the application needs data rather than prose.
• Tool access, letting agents request controlled capabilities while Laravel still performs authorization and validation.
• Operational hooks such as usage data, raw responses, events, testing helpers, failover, streaming and queue support.

Setup and configuration

Installation follows normal Laravel conventions: composer require laravel/ai, publishing the service provider's config, and running migrations. The migration step matters because features like remembered conversations need database tables, although a stateless classification or summarization endpoint may not touch conversation storage at first.

Provider credentials live in environment variables — OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY, GROQ_API_KEY and similar — rather than in prompts, controllers, jobs or agent classes. The tutorial recommends defining a default provider and model per environment: something cheap or local for development, a pinned model in production for predictable behavior and pricing. Model choice should be treated as infrastructure configuration, the author argues, since it affects quality, latency, cost, context window and supported tools.

Agents as first-class PHP classes

The agent is the SDK's main application-facing concept. A php artisan make:agent command generates a class implementing the Agent contract, using PHP attributes for settings like MaxTokens and Temperature and an instructions() method that describes both the job and its boundaries. The walkthrough's example, a SupportSummaryAgent, condenses support messages while explicitly telling the model not to invent account status, payment state or technical root causes — wording the author treats as part of the application's behavioral contract.

The article also recommends starting narrow: a single task such as ticket summarization, product description improvement, review classification or internal document Q&A makes prompt design, fallbacks, cost and success criteria far easier to control than a general-purpose assistant.

Keep the HTTP layer thin

Rather than mixing prompts, provider decisions, validation and persistence inside controllers, the tutorial keeps controllers thin and delegates to a service or action class that owns the use case. The typical request lifecycle runs: the controller authorizes access, the service builds minimal prompt context from trusted data, the agent applies its instructions and configuration, the provider runs the model, and Laravel stores, validates, logs or returns the result.

Prompts should contain only what the task requires — if a summary doesn't need billing history, don't send it, and if a user can't access a record, the model shouldn't receive it either.

Anonymous agents and usage tracking

An agent() helper supports anonymous, inline agents for experiments and one-off scripts. The guidance is to prototype quickly but promote carefully: once a workflow touches users, money, records, support decisions or private data, it should move into a named agent and a domain service, which are easier to review, test, version and observe.

Responses also expose usage data reported by the provider — input tokens, output tokens and totals — which the tutorial says should be logged from day one, alongside provider, model, prompt version, feature name, response time and failure reasons. The rationale is straightforward: a feature can work correctly and still cost too much to run.

Why it matters

Most AI SDK attention has gone to JavaScript, Python and Go ecosystems, leaving PHP developers to bolt models on with ad-hoc wrappers. A first-party Laravel package makes provider switching, structured output, tool access and cost tracking idiomatic framework concerns: credentials sit in config, agents are reviewable classes, and authorization stays in Laravel rather than in the model layer. For teams running large Laravel applications, that shifts AI integration from prototype-era glue toward something that behaves like standard infrastructure.

It is worth noting the details here come from a community-published tutorial rather than Laravel's own documentation, so specifics like class names and attribute syntax reflect that walkthrough's account of the SDK.