Laravel AI SDK 1.0 makes agents a serious Laravel building blockLaravel AI SDK 1.0 makes agents a serious Laravel building block

The hard part was never calling a model

Making an HTTP request to a language model from Laravel has never been the difficult part. The real work starts when that request needs internal data, business actions, conversation history, human confirmation, and streamed responses. At that point, a few HTTP client calls and scattered prompt strings become an integration that is hard to reason about.

Laravel AI SDK 1.0 provides an application-level structure for those concerns. It is not only a text generation wrapper: it includes agents, tools, conversation context, structured output, and background execution. For Laravel applications where AI belongs inside a business workflow, that is much more useful than another isolated API client. (laravel.com)

Agents belong with the rest of the application

The SDK treats an agent as a PHP class with instructions, tools, context, and optionally an output schema. I can generate one with php artisan make:agent, resolve it through the container with make(), and run it with prompt(). That fits naturally into a Laravel codebase where Eloquent models, policies, queues, and domain services already define the application boundaries. (laravel.com)

Tools are where an assistant starts becoming useful instead of merely conversational. An agent can expose classes implementing Tool, with a description, a parameter schema, and a handle() method that performs the actual work. That creates a controlled path for looking up orders, searching documents, preparing reports, or invoking application actions. (laravel.com)

Delegation is not architecture by itself

The SDK also supports sub-agents. An agent can return another agent from its tools() method, allowing it to delegate a focused task to a specialist with different instructions, tools, model settings, or provider preferences. That is a sensible fit for cases such as routing refund-policy questions away from a general support assistant. (laravel.com)

I would not use this as a reason to build a hierarchy of agents around every feature. Each delegation adds calls, context, latency, and more places for a workflow to fail. A sub-agent is valuable when it owns a real, bounded responsibility; otherwise, a small tool with clear authorization is usually easier to maintain.

Sensitive actions should stop for review

Human approval is one of the SDK’s most practical features. A tool can implement Approvable and use InteractsWithApprovals, which pauses execution before a sensitive or irreversible action runs. The model may propose deleting a file or changing a record, but the application still requires a human decision before proceeding. (laravel.com)

That is not a replacement for normal application authorization. The application must still verify that the person approving an action is allowed to access both the conversation and the underlying resource. The documentation also makes clear that approval flows need the paused run history to be available when execution resumes. (laravel.com)

Persistent conversations without another custom layer

With the RemembersConversations trait, the SDK can store and retrieve an agent’s history automatically. After publishing and running its migrations, an agent can start a conversation with forUser() and later resume it with continue() or continueOrStart(). That removes a good amount of repetitive chat persistence code. (laravel.com)

Persistence should not mean keeping every message forever. Conversation history may include personal data, commercial information, or tool output, so retention rules and access control still need to be designed deliberately. I would also not assume that continue() handles ownership checks for me: Laravel’s documentation says that authorization remains the application’s responsibility. (laravel.com)

Streaming and queues serve different interaction patterns

For longer answers, stream() can send generated output to the client as it arrives, while then() gives access to the completed streamed response. When work should not depend on an active web request, queue() runs the agent in the background and accepts callbacks for success or failure. Those are important primitives for real interfaces, not just demos. (laravel.com)

They do not automatically make the frontend resilient. I still need to account for reconnects, partial states, timeouts, provider errors, and tool activity during a stream. The benefit is that the SDK already has a model for those paths instead of forcing everything through a single blocking HTTP response.

A local provider without rewriting the application

For a homelab setup, the most useful option is the openai-compatible driver. Its configuration accepts a required url, an optional key, and a default text model, then the named provider can be used like any other one. The documentation explicitly mentions vLLM and local gateways as compatible endpoints, while Ollama is listed as a supported provider for text and embeddings. (laravel.com)

// config/ai.php
 
'providers' => [
    'local' => [
        'driver' => 'openai-compatible',
        'url' => env('LOCAL_AI_URL'),
        'key' => env('LOCAL_AI_API_KEY'),
        'models' => [
            'text' => [
                'default' => env('LOCAL_AI_MODEL'),
            ],
        ],
    ],
],

This keeps provider details out of the business layer. I can point LOCAL_AI_URL to vLLM or another compatible gateway on a private network, then select that provider when prompting an agent. The key is optional in this setup, although it will be sent as a Bearer token when configured. (laravel.com)

The fine print

OpenAI-compatible does not mean every local server behaves the same way. The SDK supports text generation, streaming, tools, structured output, image attachments, embeddings, and transcription for compatible providers, but the selected endpoint must actually implement the required routes and behavior. I would test tool calls, streaming, and structured output against the exact model and server before committing to a production workflow. (laravel.com)

A local model is not automatically free or operationally simple either. It trades an external API bill for CPU or GPU capacity, model storage, updates, monitoring, and network security. A homelab can be a strong choice for development, privacy, or controlled workloads, but it does not remove the infrastructure decisions.

Laravel AI SDK 1.0 does not guarantee accurate answers or make poorly designed tools safe. What it does provide is a Laravel-shaped foundation for agents, conversations, approvals, and interchangeable providers. That is the meaningful change for me: it looks less like an isolated experiment and more like a reasonable dependency for applications that need AI inside real processes.

Release source · Official documentation