Use Cases for PAPI AI versus Laravel AI

Two approaches to AI in PHP — when to use which.

PHP now has two serious options for building AI-powered applications: PapiAI and Laravel AI. Both are actively maintained, both support multiple providers, and both handle tool calling and streaming. But they take fundamentally different approaches, and choosing the right one depends on your project's architecture, requirements, and constraints.

This isn't a "which is better" comparison — it's a guide to help you pick the right tool for your use case.

The core difference

PapiAI is a standalone library. Laravel AI is a framework feature.

PapiAI's core package has zero runtime dependencies beyond PHP 8.2. It works in any PHP application — standalone scripts, Laravel, Symfony, Slim, custom frameworks, CLI tools, or long-running daemons. It provides its own agent runtime, middleware pipeline, and schema validation system.

Laravel AI is deeply integrated into the Laravel ecosystem. It leverages Eloquent, queues, events, facades, and the service container. It's designed to feel like a natural extension of Laravel, not an external library you bolt on.

This difference cascades into everything else.

When to choose PapiAI

You're not using Laravel

This is the simplest decision point. If your application runs on Symfony, a microframework, or no framework at all, PapiAI is your choice. Its Symfony bridge provides first-class bundle integration, and the standalone core works anywhere PHP does.

// Works in any PHP file — no framework needed
$agent = new Agent(
    provider: new AnthropicProvider(apiKey: $apiKey),
    model: 'claude-sonnet-4-20250514',
    tools: [$searchTool, $analyzeTool],
);

$response = $agent->run('Analyze this dataset');

You need to support multiple frameworks

If you're building a package, SDK, or internal library that needs to work across projects — some on Laravel, some on Symfony, some on neither — PapiAI's framework-agnostic core is the right foundation. Write your agent logic once against ProviderInterface, and it works everywhere.

You want fine-grained control over the agent runtime

PapiAI gives you explicit control over the agentic loop: maxTurns to limit iterations, hooks for observability at every step, a composable middleware pipeline, and tool execution you can inspect and customize. The agent is a concrete class you instantiate and configure, not a service resolved from a container.

$agent = Agent::build()
    ->provider($provider)
    ->model('claude-sonnet-4-20250514')
    ->tools([$searchTool])
    ->addMiddleware(new RetryMiddleware(maxRetries: 3))
    ->addMiddleware(new RateLimitMiddleware(maxRequests: 60, perSeconds: 60))
    ->hook('beforeToolCall', fn($name, $input) => $logger->info("Tool: $name"))
    ->maxTurns(10)
    ->temperature(0.3)
    ->create();

You need 10+ provider options

PapiAI ships with 10 LLM providers plus ElevenLabs for voice, covering cloud APIs (Anthropic, OpenAI, Google, Mistral, Cohere, Groq, Grok, DeepSeek), enterprise deployments (Azure OpenAI), and local models (Ollama). The provider interface makes it trivial to add your own.

You want structured output with schema validation

PapiAI's schema system is a first-class feature — a Zod-like API for defining the exact shape of LLM responses with type constraints, validation rules, and composable modifiers. It works across all providers that support JSON mode.

$schema = Schema::object([
    'sentiment' => Schema::enum(['positive', 'negative', 'neutral']),
    'confidence' => Schema::number()->min(0)->max(1),
    'entities' => Schema::array(Schema::object([
        'name' => Schema::string(),
        'type' => Schema::enum(['person', 'org', 'location']),
    ]))->minItems(1),
]);

Minimal dependencies matter

PapiAI's core has zero runtime dependencies. Provider packages depend only on papi-ai/papi-core and ext-curl. There's no Guzzle, no HTTP abstraction, no PSR-18 client to conflict with your existing stack. This matters in environments with strict dependency policies or in legacy projects where adding packages is contentious.

When to choose Laravel AI

You're all-in on Laravel

If your entire stack is Laravel and you want AI that feels like a native Laravel feature — using Eloquent models, dispatching to Laravel queues, firing Laravel events, configuring via config/ai.php — then Laravel AI's deep framework integration is a strength, not a limitation.

You want the Laravel ecosystem's momentum

Laravel AI benefits from the Laravel ecosystem's documentation, community, packages, and conventions. If your team already knows Laravel inside out and you want the path of least resistance, staying within the ecosystem reduces cognitive overhead.

Your AI usage is simple

If you need to make straightforward chat completion calls, generate text, or do simple tool calling within a Laravel app — and you don't need middleware pipelines, multi-provider failover, or a standalone agent runtime — Laravel AI's simpler API surface may be all you need.

Using them together

Here's something most comparisons won't tell you: you can use both. PapiAI's Laravel bridge gives you a Papi facade and service provider that coexist with Laravel AI. You might use Laravel AI for simple completions and PapiAI for complex agentic workflows that need tool calling, middleware, and structured output.

The libraries don't conflict. They solve different problems at different layers of abstraction.

Summary

Choose PapiAI when you need framework independence, fine-grained agent control, or broad provider support. Choose Laravel AI when you want deep Laravel-native integration and your scope is simpler. Both are good tools — the right choice depends on your project.