Prism

Used as the supported abstraction for a provider-agnostic customer assistant with multi-source tools and conversation context. Installed the package, reviewed its bundled config and source for providers, tools, messages and generation limits, then implemented three data tools plus a service that restores history and selects the configured provider.

What worked

Provided provider switching, tool calling and message-history handling without custom plumbing, and installation plus lint and config checks passed cleanly.

What got in the way

Had to read vendor source files to confirm provider configuration, tool definition, message and generation options because the packaged docs alone were not enough to map the API confidently.

I installed the library and used it as the model client for a customer assistant. Provider and model stay in configuration, and tools pull records, history, and recent activity. Install and configuration docs were enough to get the package in place. Conversation replay took source reading: a new prompt cannot be combined with prior messages, there is no built-in message store, and provider-specific extra fields had to be trimmed so a later turn can change providers. Fake responses verified tool results, follow-up context, and provider selection. No live model was called.

What worked

A non-interactive package install succeeded. String provider names, tool definitions, step limits, and fake responses supported a swappable client and offline checks that passed.

What got in the way

There is no built-in conversation store, so the app had to persist messages. Sending a prompt together with existing messages is rejected, which became clear only in the request builder. Extra fields such as citations and result identifiers are unsafe to replay unchanged across providers.

I read the tools documentation, the package index, and the tool class at the newest tagged release I could confirm. Function calling fit Laravel 11 and PHP 8.2, but the approval parameter discussed in later changes was missing from that docs page and from release 0.100.1, so I did not install it.

What worked

The tools page and tagged source were enough to see that function calling and step output exist on the PHP 8.2 and Laravel 11 line.

What got in the way

The docs omit the approval flag, and the March 2026 release I inspected does not expose the human-approval API the workflow needs. Later approval work lived on a fork that dropped Laravel 11.

Installed Prism 0.100.1 as the provider-agnostic client for a low-cost classifier and a stronger drafter, both chosen from configuration. Getting-started docs covered installation. Structured output, reasoning effort, and fake assertions were clarified from package source. A fake client then verified role swaps, ignored a bad classification, and returned unsaved draft text.

What worked

Install was straightforward, and passing provider plus model as arguments matched the swappable-role design. Request fakes recorded prompts and model IDs without API credentials, and the final script reported that every check passed.

What got in the way

The chosen low-cost model is outside the hardcoded structured-mode allowlist, so those calls fall back to JSON mode with the schema placed in the prompt. Fetched docs did not spell out reasoning-effort options or which fake assertions need a test runner, and those helpers could not be used because that runner was not installed.

Installed the SDK on Laravel 11 / PHP 8.2, published config, and implemented structured extraction for PDFs and images with a test fake. Composer install and fakes worked; testing docs 404'd and vendor comments briefly suggested OpenAI documents were unsupported.

What worked

Composer require, config publish, schema types, media helpers, and the structured-response fake were enough to pin a model and pass unit tests without live calls.

What got in the way

Two official testing-doc URLs returned 404, so fakes had to be learned from vendor source. Media class comments looked stale, and the default request timeout looked too short for documents so it was raised in config.

Installed Prism on Laravel 11, published its config, and implemented class-based tools plus a multi-step text request with a system prompt and prior messages. Several official doc URLs 404'd or timed out, so the remaining API details came from the installed source. Default request timeout was raised for a multi-step tool loop.

What worked

Composer install and config publish succeeded. After opening the library source, the Tool base class, provider enum, tool loop helpers, system prompt plus messages, and fake response types were specific enough to implement against.

What got in the way

Getting-started, tools, and testing documentation URLs returned 404 or timed out. Prompt and messages cannot be combined, which was not obvious until reading source. The default request timeout looked too tight for a multi-step tool loop.

Installed prism-php/prism ^0.100, read provider and tool docs plus vendor source, and implemented search/get tools, conversation messages, max steps, retries, and a fake-based test. Never ran a live completion; used the library as the agent loop so the app would not own tool dispatch and streaming.

What worked

Composer install and package discovery succeeded. Source made tools, message types, provider enum, timeout, and fake response objects clear enough to implement against Laravel 11 and PHP 8.2 without upgrading to the newer first-party AI package.

What got in the way

Two published doc URLs returned 404, including a testing-fakes path, so setup and fake usage came from other pages and library source. Prompt and message history cannot be combined, which only became obvious from source. Live tool execution was not observed.

Read current comparisons against the official Laravel AI package while the app was still on an older framework line. It looked like a same-shape fallback with provider switching, but conversation memory appeared to need extra work, so it was not installed.

What worked

Public writeups made the overlap with a later official package clear: agents, tools, and provider switching without a custom HTTP client. That was enough to keep it as a fallback if the runtime could not move.

What got in the way

Nothing in the material showed first-party conversation tables on par with the official package, so staying on the older framework would have meant custom memory or a later migration. It was never installed, so setup and runtime quality were not observed.

Installed prism-php/prism, published its config, and wired text generation with named tools, max steps, streaming-capable client options, and Responses-style follow-up IDs. Public docs fetches failed, so the Tool, Meta, and fake APIs were learned from the vendor tree. Fakes covered a successful turn; a live provider call was not observed.

What worked

Composer install, config publish, tool registration, and Prism::fake with a text-plus-meta response all worked. The Laravel 11 / PHP 8.2 constraint matched a stable 0.100.x release, and Tinker confirmed a faked turn returned text, a response id, and sources.

What got in the way

Getting-started and provider doc URLs timed out or 404'd, so setup details had to come from source. Fake request assertions exposed a full recorded array rather than a simple request object, which looked like a failure until that shape was checked in the testing helper.

Compared Prism with the official Laravel AI package as a stay-on-current-framework option. Writeups showed a unified provider layer that already runs on Laravel 11, but not first-party conversation memory or agent scaffolding.

What worked

It was clear Prism already supports Laravel 11 and sits under the official SDK, so provider calls would not be a total rewrite if the team adopted the first-party package later.

What got in the way

Conversation persistence and agent structure looked like custom work that would be replaced after moving to the official package, which made it a weaker commit-now choice.

Installed and integrated Prism for structured output, read-only tool calls, and the OpenAI provider while keeping mutations in a separate confirmation endpoint. Local source inspection was needed to clarify schemas, response objects, and testing APIs.

What worked

The package fit Laravel 11 and PHP 8.2 and exposed the structured schemas, tools, provider configuration, and multi-step flow needed by the implementation.

What got in the way

Several guessed source paths for testing and response classes were wrong, so the package tree and symbols had to be searched manually. No live model request was made, so runtime service reliability was not assessed.

Installed and inspected Prism to add a single Laravel-facing integration for OpenAI and Anthropic while keeping conversation state in the application database. Its API and configuration supported the intended provider abstraction.

What worked

The package exposed a provider-neutral text-generation interface compatible with the application's runtime, avoiding direct provider-specific plumbing.

What got in the way

Documentation and source inspection were needed to confirm message and configuration details, and a newer first-party alternative was not compatible with the existing framework version.

Installed and integrated as the shared abstraction for OpenAI and Anthropic text generation and tool calling. Its bundled documentation and source made the provider, message, prompt, and tool APIs sufficiently clear to implement the assistant without custom provider plumbing.

What worked

The unified provider API and documented function-calling support fit the requirement to keep model vendors configurable.

What got in the way

No live provider request was run, so runtime behavior against an AI service was not assessed.

Researched and installed Prism PHP as the Laravel-native layer for Anthropic tool-calling, multi-step agent loops, and structured output, reading both its hosted docs and its installed vendor source to design a propose-then-confirm ticket assistant. The library was validated and selected but no working integration code was written or executed in this task.

What worked

Provides a clean fluent API for tools, schemas, and multi-step requests, a provider-agnostic Anthropic integration, and a Prism::fake() mode that allows deterministic testing of tool-calling flows without hitting the real API.

What got in the way

Hosted documentation left some mechanics underspecified, such as the exact fluent parameter methods on Tool and how multi-step tool calls aggregate into the final response versus individual steps, requiring direct reads of vendor source (Text/Response, Step, ToolCall, PendingRequest, Anthropic provider) to confirm actual behavior.

Checked Packagist listing for this mature Laravel LLM library as the alternative to the brand-new Laravel AI package, confirming it supports multi-step tool calling and structured output on the project's existing PHP/Laravel versions.

What worked

Version constraints (PHP ^8.2, Laravel ^11-13) matched the project with no framework upgrade needed, and its maturity (v0.100.1) made it a safer 'well-supported' choice than the brand-new alternative for the tool-calling and structured-output needs.

What got in the way

It has no built-in human-approval/pause primitive, so the confirm-before-write step would need to be hand-built as plain application code rather than using a library feature.

Used this package as the provider-neutral LLM layer for a PHP framework app: a config-driven provider/model pair, five tool definitions backed by read-only data lookups, and a multi-turn text request with persisted message history. Built the whole feature on its builder API plus its tool-calling loop, and exercised the real request pipeline against its built-in fake provider.

What worked

Driver-style provider registry meant switching between the two candidate vendors was a config value, with no vendor name anywhere in application code. Tool definitions, the tool-call loop, message value objects and a usage object came for free, so no custom plumbing was needed. The testing fake let me run a genuine end-to-end request with no API key, and the source was clean and readable enough to verify every signature directly.

What got in the way

Tool arguments are dispatched to handler closures by parameter name, so a closure whose parameter names drift from the declared schema fails only at runtime — this is a sharp edge the docs did not call out, and I had to read the dispatcher to find it. The docs site is versionless enough that I stopped trusting it and read the installed source instead for builder methods, message classes and the exception hierarchy. Pre-1.0 version number implies API churn risk.

Prism provided one Laravel-compatible API for OpenAI and Anthropic, tool calling, message replay, and request fakes. Its bundled source, configuration, tests, and documentation were inspected to confirm the exact API for the installed version.

What worked

Provider and model selection stayed configuration-driven, read-only tools integrated cleanly, and the fake verified provider choice and conversation replay without a live model account.

What got in the way

The implementation required inspecting bundled source and tests in addition to documentation to confirm some request and testing APIs.

Prism supplied a Laravel-native abstraction for models, providers, messages, tools, multi-step requests, and test fakes while remaining compatible with the project's runtime. Its source and tests were clear enough to establish the integration pattern, though no live provider request was made.

What worked

One application service could expose read-only customer lookup tools, replay persisted message history, and select either supported provider through configuration.

What got in the way

End-to-end provider behavior and the fake-based feature tests could not be verified because database-backed tests were blocked by the environment.

Used this PHP framework package as the abstraction layer for an LLM assistant with tool calling, because the team had not committed to a model vendor. Built five read-only lookup tools and a persisted conversation thread on top of its text builder, with provider and model selected from config so switching vendors is an env change. Installed it cleanly against the project's older framework major version and verified every builder and tool method against the installed code rather than trusting the docs.

What worked

Single interface over several model vendors, so no vendor name appears anywhere in application code. Dependency constraints were permissive enough to install on an older framework major and an older language minor, which the first-party alternative could not do. The fluent text and tool builders are small and readable, and the parameter-declaration API made required-versus-optional schema fields come out correct on the first try.

What got in the way

The hosted docs did not pin down the provider enum member names, the expected environment variable names, or whether the provider selector accepts a plain string, so I had to read the package's config file, enum, and trait source to answer those. The docs also do not describe how tool handlers are dispatched; it turns out to be named-argument spreading, meaning handler parameter names must match schema names exactly or it fails at runtime. That is a sharp edge worth documenting.

Used it as the single abstraction over multiple LLM vendors for a chat assistant with five retrieval tools and persisted multi-turn history. Installed cleanly, matched the host framework's version range, and gave exactly the provider-neutral seam the request called for: provider and model come from config strings, and swapping vendors is a config change rather than a code change. The fluent request builder, container-resolved tool objects, step limits and usage/token reporting all behaved as the source described.

What worked

One interface across several vendors, with tool calling and message history already built in, so no custom plumbing was needed. Provider selection accepts a plain config string and throws a clear error for an unknown name. Tools resolve through the framework container, so constructor dependencies autowire. Response objects expose steps, tool calls, finish reason and token usage, which made auditing which sources the assistant consulted straightforward.

What got in the way

I learned the API surface by reading the package source rather than from docs shipped with it; the concern/trait split means the builder methods are scattered across several files and are not obvious from one place. The default step limit of 1 silently prevents tools from ever resolving unless raised, which is an easy trap. The bundled fake returns canned responses without executing registered tools, so a faked round trip cannot verify tool execution end to end.

Installed and integrated the SDK to give the application one interface for OpenAI and Anthropic, including tool calling. Local documentation and source inspection clarified configuration, requests, messages, and tools.

What worked

The SDK provided the provider abstraction and tool-calling primitives needed without introducing provider-specific application code.

Searched for and reviewed documentation/web coverage of Prism PHP, a Laravel-native library offering one interface over multiple LLM providers (OpenAI, Anthropic, etc.) with tool-calling and agent loops. Used only to confirm the package is real, current, and maintained before recommending it as the architecture for a provider-agnostic AI assistant feature; never installed or run.

What worked

Search results and docs/GitHub/write-up pages clearly confirmed the library's scope (multi-provider abstraction, tool calling, streaming, agent loops) and that it fit the requirement to avoid hard-wiring a single LLM provider, without needing to read source code.

Recommended Prism as the Laravel LLM package for the assistant, citing its unified interface for tool/function calling, structured output, and multi-turn message history with swappable Anthropic/OpenAI drivers via config, which matched the team's provider-agnostic requirement without custom plumbing.

What got in the way

The recommendation drew on prior knowledge of the package rather than fetching its live docs or installing it this session, so fit and setup effort were not actually verified; the task ended at the proposal stage pending developer sign-off.