DEV Community: Kavita Systems

Modernizing Legacy Laravel Apps with Figma Agents, and Smarter Tests

VitaliiK — Thu, 25 Jun 2026 13:36:32 +0000

The biggest AI opportunity in web development might not be the next shiny app.

It might be the old one your company is afraid to touch.

Every day, businesses run on software that still works but no longer feels modern: old admin panels, internal CRMs, Laravel dashboards built years ago, Blade views nobody wants to refactor, reporting tools with confusing filters, support screens with too many columns, and customer portals that still make money but slow down every new feature.

That is where things get interesting.

Most AI conversations focus on building something new from scratch. A founder has an idea, generates a prototype, writes code with an AI assistant, connects a model API, and launches an MVP.

That is a real use case, and it matters.

But most software work does not start with a blank repository. It starts with an existing product, existing users, existing data, existing bugs, existing business rules, and years of decisions that made sense at the time.

AI is not just a startup accelerator.

It is becoming a modernization engine.

The next wave of AI in web development will not only be about launching new products faster. It will also be about upgrading the products companies already depend on.

The real opportunity is not another chatbot

A lot of “AI-powered” products follow the same pattern: take an existing app, add a chat window, and call it innovation.

That is not enough.

A support dashboard does not need a chatbot in the corner. It needs ticket summaries, priority detection, suggested replies, and better routing.

A CRM does not need a generic assistant. It needs account summaries, follow-up suggestions, risk signals, and smarter search.

An accounting tool does not need AI decoration. It needs invoice classification, document extraction, anomaly detection, and review workflows.

The best AI features do not feel like separate products. They feel like the existing product got smarter.

AI should not sit next to the product. AI should make the product better.

That is the key difference.

AI should remove friction from the workflow people already use every day. It should reduce repetitive work, surface useful context, help users make decisions faster, and keep humans in control where judgment matters.

There are two AI development paths now

AI is changing product development in two very different ways.

The first path is greenfield development. This is the startup path. You begin with an idea, write a product brief, explore the interface in Figma, create a functional prototype, validate the flow with users, then build the real application with Laravel, an AI coding agent, and the Laravel AI SDK.

This is powerful because the cost of going from idea to working product has dropped dramatically.

The second path is brownfield modernization. This is the path most real companies need. You already have a working product. Maybe it is profitable. Maybe users rely on it every day. But the UI feels outdated, the codebase has too many patterns, the product is hard to extend, and every improvement feels risky.

This path is not about moving fast and breaking things.

It is about improving one valuable workflow at a time without breaking the business.

Same tools. Different mindset.

For a new product, the question is: how quickly can we validate this idea?
For an existing product, the question is: how can we make this system better without turning modernization into a six-month rewrite?

AI helps with both, but the second opportunity may be much larger.

Start with the workflow, not the model

The biggest mistake teams make is starting with the tech stack.

They ask which model to use, which IDE assistant is better, whether to use React or Livewire, whether they need vector search, or whether they should build an agent.

Those questions matter, but they are not the starting point.

The starting point is the workflow.

What does the user do every day?
Where do they waste time?
Where do they copy and paste?
Where do they wait?
Where do they make mistakes?
Where do they need context before making a decision?
Which part of the workflow is repetitive enough to automate but important enough to improve?

“Modernize our app” is too vague.

“Help support managers review, prioritize, and respond to tickets faster” is specific.

That kind of problem gives every tool a clear job.

Figma helps rethink the user experience. Figma Make helps test the improved flow before production work starts. Figma MCP helps move real design context into the coding environment. An AI coding agent helps inspect the existing codebase and implement focused changes. Laravel provides the application structure. Laravel AI SDK adds intelligent behavior where it actually belongs.

That is a real workflow.

Figma agents are becoming real product tools

Figma’s recent AI updates are important because the agent is no longer just a prompt box that creates a few screen ideas.

Figma has been expanding its design agent with more context, custom tools, reusable skills, and deeper connections to design and development workflows. This direction moves beyond simple prompting toward agents that understand how a team works, use broader project context, and help create reusable tools directly on the canvas.

For modernization work, this matters because context is everything.

If you are redesigning an old support dashboard, you do not want a random “modern SaaS UI.” You want a better version of the actual workflow your team already uses.

That means the agent should understand the current screen, the design system, user feedback, accessibility rules, product requirements, and the business goal behind the redesign.

This is where Figma’s agent becomes useful. It does not replace the designer. It helps the team move from vague feedback to concrete options faster.

Instead of starting from a blank canvas, a team can explore several improved versions of the same workflow, compare them, clean up the hierarchy, standardize components, and create better empty, loading, and error states.

The goal is not to make the old screen prettier.

The goal is to make the workflow easier to understand and faster to use.

Code layers make design and code feel closer

Another important Figma update is code layers.

Code layers bring interactive code onto the Figma canvas. Teams can create a code layer from a frame, ask the Figma agent to generate one, bring in a repository, or upload a local folder. This creates workflows where teams can compare, refine, and update code layers alongside normal design work.

This is especially interesting for legacy products.

Historically, modernization projects often started with screenshots of the old product. Screenshots are useful, but they are dead artifacts. They do not show real behavior, real state, real components, or the connection between design and implementation.

Code layers make the design conversation more practical.

Designers, developers, and product managers can compare the current experience with a proposed future experience in a more interactive way. They can discuss what is purely visual, what requires frontend work, and what depends on backend logic.

This does not mean Figma becomes your production IDE.

It means the gap between “what exists,” “what we designed,” and “what we plan to build” gets smaller.

Figma MCP reduces design-to-code guesswork

Design-to-code has always had a translation problem.

A designer creates a screen. A developer interprets it. Something gets lost. Spacing changes. Components get duplicated. States are forgotten. A table gets rebuilt from scratch even though the app already has one. A modal looks almost like the design system, but not quite.

AI can make this worse if it only works from screenshots or vague prompts.

That is why the Figma MCP Server matters.

Figma MCP can provide AI agents with design context from Figma files, including selected frames, components, variables, layout data, and resources from Figma Make files.

For modernization, the coding agent needs to understand two worlds at the same time:

the existing Laravel application;
the new Figma design direction.

If the agent only understands the old code, it may preserve outdated UI patterns. If it only understands the new design, it may produce code that does not fit the actual application.

But when it has both design context and codebase context, it can make more precise changes.

That is when AI becomes useful in real projects.

Not as a magic generator, but as a context-aware assistant.

Code Connect helps prevent component chaos

One of the easiest ways to damage a codebase with AI is to let it create duplicate components.

A new button. A new card. A new modal. A new table. A new dropdown. A new form pattern.

None of them are terrible alone, but together they create a maintenance problem.

After a few weeks, the app may look “AI-modernized,” but the codebase is harder to maintain than before.

Code Connect helps by linking Figma components to real code components. It connects design components with their implementation in code, which helps teams keep design and engineering aligned.

The button in Figma should map to the real button in code. The modal should use the existing modal. The table should follow the existing table pattern. The badge should not be recreated five different ways.

In a new product, this keeps things clean from the beginning.

In a legacy product, it is even more important because modernization should reduce inconsistency, not add more.

AI agents need boundaries. A connected design system gives them those boundaries.

AI in PhpStorm and other IDEs belongs in the real developer workflow

After the new flow is validated in Figma, the work moves into the IDE.

For PHP teams, PhpStorm is one of the most natural places for AI-assisted development. JetBrains AI Assistant supports modern PHP development workflows such as generating and explaining PHP code, multi-file edits, intelligent completion, and AI chat with project context.

JetBrains also has Junie, an AI coding agent that can work in code mode to execute tasks and in ask mode to collaborate on plans and questions.

If your team does not use PhpStorm, the same workflow can work with alternatives such as Cursor, Claude Code, or GitHub Copilot.

The specific tool matters less than the operating model.

A bad prompt is:

Refactor this dashboard.

A better request is:

Explain how this workflow works today. Identify its routes, controllers, models, policies, frontend components, jobs, and tests. List the business rules that must be preserved. Then propose a modernization plan without editing any files.

The agent’s first job should be understanding, not implementation.

After the plan is reviewed, let it change one vertical slice at a time. A ticket detail screen is a reasonable task. An entire support system is not.

Laravel now has an AI stack, not just an AI package

Laravel is especially interesting in this workflow because it has structure.

Routes have a place. Controllers have a place. Models have a place. Migrations have a place. Policies have a place. Jobs have a place. Tests have a place.

That structure helps humans, but it also helps AI agents.

Laravel’s AI tooling now operates at several layers.

Laravel Boost helps AI coding agents write better Laravel code by giving them Laravel-specific context, guidance, and project-aware tools.

Laravel AI SDK helps developers build AI features inside Laravel applications. It provides a Laravel-native way to build AI-powered features with providers, agents, tools, structured output, embeddings, vector workflows, and more.

Laravel MCP helps AI clients and agents interact with tools and resources exposed by Laravel applications. Laravel AI agents can also connect to MCP servers and work with external systems.

These tools solve different problems:

Boost helps AI write the application.
AI SDK helps the application use AI.
MCP helps AI interact with the application and external systems.

A production project may use all three, but it should not install all three simply because they exist.

Start with the workflow. Then choose the tool.

AI can help with framework upgrades too

Legacy modernization is not only about redesigning screens.

It often includes framework upgrades, package updates, new PHP versions, deprecated APIs, test-suite changes, and cleanup around old patterns.

AI-assisted upgrade workflows can help teams compare package versions, follow official upgrade guidance, update repetitive code, run the test suite, and report what still fails.

That does not make an upgrade automatic or risk-free.

An AI agent cannot know every undocumented production dependency, every unusual database record, or every client-specific behavior.

But it can turn an upgrade from a manual search-and-replace exercise into a structured engineering loop.

The team still owns the final diff.

Tests are the safety system for AI-assisted modernization

AI is useful in legacy work only when it makes change safer.

Before asking an agent to refactor old code, use it to help document and test the existing behavior.

These are often called characterization tests: they capture what the application does today, including behavior the team may not fully understand.

For an old support dashboard, that might include authorization rules, filters, sorting, ticket assignments, status transitions, notifications, exports, and tenant isolation.

Once those behaviors are protected, the agent can refactor with a clear signal when something breaks.

AI assistants can help generate unit tests in the IDE and show proposed test code for review.

But this part is important: an AI-generated test is not automatically a good test.

Sometimes the test simply repeats the same wrong assumption as the generated code. Sometimes it tests implementation details instead of behavior. Sometimes it misses authorization, edge cases, failure states, or multi-tenant boundaries.

The developer still needs to ask:

Is this testing behavior or implementation details?
Does it cover authorization?
Does it cover another tenant trying to access the record?
Does it cover invalid and incomplete data?
Does it cover failure and retry states?
Would this test have caught the original bug?
Did the agent weaken an assertion just to make the suite pass?

The goal is not more tests.

The goal is more confidence.

Laravel PAO makes the test loop better for agents

Laravel recently introduced PAO, or PHP agent-optimized output.

Test runners and analysis tools normally produce terminal output designed for humans: colors, progress dots, tables, warnings, and decorative formatting.

That output can waste context and make it harder for an AI agent to locate the actual failure.

Laravel PAO returns compact, structured output for supported commands when they are being run by an AI agent.

This sounds like a small feature, but it improves the most common agent loop:

Run the tests.
Find the failure.
Edit the relevant code.
Run the tests again.

When an agent receives the failing assertion, file, line number, and error details directly, it spends less time interpreting terminal noise and more time solving the actual problem.

AI features need their own testing strategy

Adding an AI-powered feature creates a second testing problem.

The application logic may be deterministic, but the model output is not.

Suppose the modernized support dashboard includes an AI-generated ticket summary. A normal test should not call a live provider and compare the exact paragraph returned by the model. That would be slow, expensive, and unreliable.

Instead, the regular application suite should test deterministic boundaries:

Was the correct agent invoked?
Was the job dispatched?
Was tenant authorization enforced?
Was the result stored in the correct record?
Did the response match the expected structured schema?
Was the failure state handled?
Was an automatic action blocked until human approval?

Laravel AI SDK includes testing helpers such as fakes and assertions for AI operations, allowing teams to test application behavior without making uncontrolled live model calls.

Model quality should be evaluated separately.

Keep a small set of representative examples and expected qualities: correct category, acceptable summary, no invented facts, no cross-tenant data, appropriate escalation, and no unsafe action.

Unit tests protect the application.

Evaluations protect the AI behavior.

You need both.

A practical modernization flow

Imagine an old customer-support dashboard built in Laravel.

It still works, but the ticket table has too many columns, filters are inconsistent, the detail page is difficult to scan, and support managers spend too much time reading repetitive requests.

A practical AI-assisted modernization flow could look like this.

1. Protect the current behavior

Before redesigning anything, map the existing route, controller, policies, database queries, frontend components, jobs, and notifications.

Ask the coding agent to identify missing coverage, then add characterization tests for the behavior users depend on.

Do this before the refactor, not after it.

2. Redesign the workflow with Figma’s agent

Bring the current interface, user feedback, support metrics, design system, and project requirements into Figma.

Ask the agent to explore a cleaner ticket inbox and a more focused ticket detail page.

Create reusable rules or skills that enforce the team’s component, accessibility, and layout standards.

The goal is not a beautiful concept.

The goal is a better working day for the support team.

3. Validate the interaction

Use Figma Make or code-layer workflows to create a working version of the new flow.

Let real support managers use it.

Watch where they hesitate. Check whether the AI summary helps or distracts. Confirm which information they need before approving a suggested response.

Fix the workflow before rebuilding the backend.

4. Connect the design to the real codebase

Use Figma MCP to provide the selected design context to the coding agent.

Map important design components to production components with Code Connect.

The agent should know which table, button, modal, badge, and form components already exist.

5. Implement one vertical slice

In PhpStorm with Junie, or in Cursor, Claude Code, or GitHub Copilot, ask the agent to inspect the existing implementation and propose a plan.

Start with the ticket detail page. Keep the old route available. Ship the new version behind a feature flag. Run the existing and newly generated tests after every meaningful change.

Do not modernize the entire support module in one task.

6. Add one narrow AI feature

Once the new workflow is stable, add ticket summarization through Laravel AI SDK.

Do not begin with full automation. The first version can summarize the request, classify it, suggest urgency, and draft a response for human approval.

That is useful, measurable, and relatively safe.

7. Test, release, and measure

Fake model responses in the normal test suite. Evaluate model quality separately. Use agent-friendly test output to improve the feedback loop. Release the new workflow to a small group and measure review time, error rate, adoption, and support-team feedback.

Then decide whether the next investment should be smarter routing, suggested replies, better search, or simply another redesigned screen.

Guardrails matter more than prompts

A coding agent working in a legacy product should have explicit boundaries.

It should not rewrite unrelated files.
It should not introduce a new frontend framework without approval.
It should not create duplicate components.
It should not change the database schema without a migration and rollback plan.
It should not weaken tests to make them pass.
It should not bypass policies or tenant boundaries.
It should not send sensitive production data to an external model without an approved data policy.

The agent can inspect, plan, implement, run tests, and review the diff.

The team still owns the architecture, security, product decisions, and release.

That is the real AI modernization stack: not one model and not one magic prompt, but a connected workflow with context at every stage.

Figma’s agent helps the team rethink the experience. Figma MCP and Code Connect carry design intent into development. PhpStorm, Junie, Cursor, Claude Code, or GitHub Copilot help engineers understand and change the codebase. Laravel Boost gives those agents framework-specific context. Laravel AI SDK adds useful intelligence to the product. Tests, fakes, evaluations, and agent-friendly output keep the process under control.

The goal is not to generate more code.

The goal is to improve valuable software without putting the business at risk.

At Kavita Systems, we help teams modernize existing web products, improve legacy Laravel workflows, and introduce practical AI features without committing to a risky full rewrite.

Need to understand where AI can create value in your existing product?

Laravel 13 Makes the “AI Means Python” Argument Weaker

VitaliiK — Wed, 24 Jun 2026 12:07:59 +0000

For a long time, adding AI to a Laravel product usually meant one thing: you had to bring another service into the stack.

The architecture often looked like this:

At first, this setup feels reasonable.

Laravel handles the product. Python handles the AI. FastAPI or Flask sits in the middle. The bridge sends text to an embeddings service, talks to a vector database, calls an LLM provider, and sends the answer back.

For a prototype, that is fine.

For a demo, it may even look impressive.

But then the product goes live.

And suddenly that “small Python bridge” is not small anymore. It needs deployment, monitoring, logs, retries, permissions, rate limits, error handling, security reviews, and someone on the team who understands why a payment flow in Laravel now depends on a Python service nobody wants to touch.

The problem was never Python itself.

The problem is using Python as a bridge only because Laravel used to have no native way to deal with AI workflows.

That is changing.

With Laravel 13 and the Laravel AI SDK, many things that previously required a separate Python service can now live inside the Laravel application: agents, tools, embeddings, vector search, RAG workflows, and AI provider orchestration.

Laravel also supports vector columns in PostgreSQL through pgvector, so semantic search can sit much closer to your Eloquent models, policies, queues, and business logic.

This does not mean Python is dead.

It means the Python bridge is no longer the default answer.

The Problem Was Never Python

Python is still great for machine learning research, notebooks, model training, data science, experiments, and custom ML pipelines.

If your team is training models or building research-heavy AI infrastructure, Python probably still belongs in your stack.

But most product teams are not doing that.

Most product teams want something much more practical.

They want to search a product catalog by meaning. They want to answer questions using internal documentation. They want to explain payment errors, help users book a service, prepare a stock order, summarize support tickets, or route a request to the right workflow.

That is not machine learning research.

That is application engineering.

And application engineering is exactly where Laravel is strong.

The real question is not:

Can Python do this?

Of course it can.

The better question is:

Do we need a separate Python service only to call an LLM, generate embeddings, search vectors, and trigger business workflows?

In many Laravel products, the answer is now: no.

What We Are Actually Killing

We are not killing Python.

We are killing an awkward split in the architecture.

Think about a real product.

Laravel knows the user. Laravel knows the order. Laravel knows the permissions. Laravel knows the payment state. Laravel knows the booking rules. Laravel knows the audit log.

But then we ask a separate Python service to make the AI decision.

That split feels wrong because the AI layer is not floating somewhere outside the product. It is supposed to help the product make better decisions, explain things better, and guide users through existing workflows.

If the business logic already lives in Laravel, the AI workflow should be close to that business logic.

With a native Laravel AI stack, the architecture becomes much easier to understand:

The user talks to the Laravel application. The Laravel application calls an AI agent. The agent uses allowed tools. The tools call Eloquent models, external APIs, policies, queues, and services. The LLM helps understand language, but Laravel still controls the workflow.

That means one codebase, one permission model, one deployment pipeline, one logging system, and one team that can understand the full flow.

That is the real win.

RAG Is Not Just “Chat With PDF”

A lot of people still imagine RAG as a chatbot that reads PDFs.

That is the beginner version.

In a real product, RAG is more useful than that. It is a way to give the AI the right business context before it answers or acts.

That context can come from many places:

But here is the important part: RAG should not become your source of truth.

RAG is great for finding, explaining, comparing, summarizing, and suggesting.

But real product actions still belong to your domain APIs.

An AI agent can help a user choose a laptop. But the catalog API must confirm the actual price and inventory.

An AI agent can explain a cancellation policy. But the booking API must confirm whether this specific reservation can still be canceled.

An AI agent can prepare a stock order. But the brokerage system must execute it only after confirmation, risk checks, and compliance rules.

This is the line that matters:

AI can help the user understand and prepare the action. The backend must still validate and execute the action.

Why Native Vector Search Matters

Before native vector support, adding AI search to Laravel usually meant adding more infrastructure.

You had Laravel for the product, FastAPI for the bridge, LangChain or custom orchestration for the AI flow, OpenAI or another model provider, Pinecone or another vector database, Redis or queues, custom sync jobs, and custom observability.

That is a lot of moving parts for a feature that may start with one simple question:

Can users search our data by meaning instead of exact keywords?

Now many teams can start much simpler.

For example, a product table can store an embedding directly in PostgreSQL:

<?php

Schema::ensureVectorExtensionExists();

Schema::create('products', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->text('description');
    $table->json('attributes')->nullable();

    $table->vector('embedding', dimensions: 1536)->index();

    $table->timestamps();
});

And semantic search can stay inside Eloquent:

<?php

$products = Product::query()
    ->where('is_active', true)
    ->whereVectorSimilarTo(
        column: 'embedding',
        value: 'a lightweight laptop for Figma, coding, and video calls',
        minSimilarity: 0.55,
    )
    ->limit(10)
    ->get();

This is not only about writing fewer lines of code.

It is about keeping search close to your existing models, filters, tenant scopes, policies, queues, and database logic.

When retrieval lives inside the same application, it is easier to reason about who can see what, what should be indexed, and what should never be exposed to the model.

Example 1: E-Commerce Search That Understands Human Requests

Traditional product search works well when the user knows exactly what they want:

iPhone 15 Pro 256GB
Nike Air Max size 10
Logitech MX Master 3S

But real users do not always search like that.

Sometimes they write:

I need a gift for someone who travels a lot.

Find me a laptop for design work and Laravel development.

Show me something useful for a home office under $300.

Keyword search can easily miss the intent behind these requests.

Semantic search works better because it compares meaning, not just words.

A product search tool can look like this:

<?php

final class SearchProductsTool
{
    public function handle(string $query, ?int $maxPrice = null): array
    {
        return Product::query()
            ->where('is_active', true)
            ->when($maxPrice, fn ($q) => $q->where('price', '<=', $maxPrice))
            ->whereVectorSimilarTo(
                column: 'embedding',
                value: $query,
                minSimilarity: 0.55,
            )
            ->limit(10)
            ->get([
                'id',
                'name',
                'price',
                'short_description',
            ])
            ->toArray();
    }
}

Now the user can say:

I need a compact gift for a colleague who flies twice a month.

The system can return travel adapters, power banks, compact headphones, laptop sleeves, or carry-on accessories even if the user never typed those exact words.

That is not just a “cool AI feature.”

That is a better shopping experience.

Example 2: Booking Systems Where AI Understands the Intent

Booking platforms are full of rules.

Cancellation windows. Slot availability. Deposits. Staff schedules. Seasonal prices. Minimum duration. No-show rules. Different policies for different services.

Users do not want to read all of that.

They want to ask simple questions:

Can I book a massage for two people this Saturday after 4 PM?

Find me an apartment in Lviv for the weekend with parking and free cancellation.

Can I cancel my booking if check-in is tomorrow?

AI is useful here because it can translate messy human language into a clean backend workflow.

It can search the policy documents, understand the request, and call the booking API to check real-time availability.

<?php

final class CheckAvailabilityTool
{
    public function handle(array $payload): array
    {
        return app(BookingApi::class)->availableSlots(
            service: $payload['service'],
            date: $payload['date'],
            guests: $payload['guests'] ?? 1,
            after: $payload['after'] ?? null,
            maxPrice: $payload['max_price'] ?? null,
        );
    }
}

A healthy booking flow should look like this:

The AI should not randomly finalize a reservation.

It should not guess dates. It should not ignore cancellation rules. It should not bypass your booking engine.

AI helps the user move faster.

Laravel still owns the transaction.

Example 3: Payments, Banking, and Stock Orders

Financial workflows are where AI needs the shortest leash.

A user might say:

Buy $500 worth of Apple stock if the fee is under $2.

Can I pay this invoice from my business account?

Why was my card payment declined?

AI can help with all of these requests.

But it should not directly move money without confirmation.

In payments, banking, and brokerage systems, the AI should usually do three things: explain what is happening, prepare the next step, and verify the conditions.

It should not silently execute a payment, bank transfer, refund, or stock trade.

A safer brokerage flow looks like this:

User asks to buy stock.
AI checks account status.
AI gets quote and estimated fees.
AI checks available balance.
Laravel creates a pending trade.
User reviews and confirms.
Backend executes the trade.

The AI-facing tool should create a pending trade, not execute the order:

<?php

final class CreatePendingTradeTool
{
    public function handle(string $symbol, float $amount): array
    {
        Gate::authorize('createTradeIntent', auth()->user());

        $quote = app(BrokerageApi::class)->quote($symbol);
        $fees = app(BrokerageApi::class)->estimateFees($symbol, $amount);

        $trade = PendingTrade::create([
            'user_id' => auth()->id(),
            'symbol' => $symbol,
            'amount' => $amount,
            'quote_snapshot' => $quote,
            'estimated_fees' => $fees,
            'status' => 'awaiting_confirmation',
        ]);

        return $trade->toArray();
    }
}

The final execution should stay inside the normal backend flow, with transactions, risk checks, policies, and audit logs.

The same idea applies to payments.

AI can create a payment intent. AI can explain why a transaction failed. AI can suggest another payment method.

But it should not bypass 3DS, fraud checks, limits, compliance rules, or explicit user confirmation.

That is not an AI limitation.

That is responsible engineering.

How to Put It Together in Laravel

A clean Laravel AI architecture can be organized around agents and tools.

The agent understands the user request. The tools define what the AI is allowed to do. Laravel services handle the real business logic.

Agents: CommerceAgent, BookingAgent, BankingAssistantAgent.
Tools: SearchProductsTool, CheckAvailabilityTool, CreateReservationHoldTool, CreatePaymentIntentTool, CreatePendingTradeTool, SearchPolicyDocumentsTool.
Services: CatalogApi, BookingApi, PaymentGateway, BrokerageApi, RiskService.
Models: Product, Booking, Payment, PendingTrade, PolicyDocument.

The most important idea is simple:

An AI agent should not be a god object. It should be a controlled interface between the user, the LLM, and your backend.

For example, a commerce agent may be allowed to search products, check delivery availability, create reservation holds, and prepare payment intents.

But it should not be allowed to execute payments, trades, refunds, or final bookings without explicit confirmation and server-side validation.

This is the mental model:

The LLM understands the request.
The agent decides which tools are allowed.
The tools call the real backend.
Laravel enforces permissions and policies.
The user confirms critical actions.
The system logs everything.

That is production architecture.

Not magic.

The Three-API Pattern

Most useful AI products are not just “LLM plus database.”

They are integrations.

This is where Laravel third-party API integration becomes more than a technical task. It becomes the layer that connects AI intent with real product systems: marketplaces, booking engines, payment gateways, banking APIs, and brokerage platforms.

Imagine an AI-powered commerce platform with three external APIs:

Marketplace API: products, prices, inventory, and attributes.
Booking API: delivery slots, appointments, and reservations.
Payment, banking, or brokerage API: payment intents, balances, fees, and stock orders.

Without AI, the user has to move through all these systems manually.

With AI, the user can simply say:

Find me a laptop for design work under $1,500, deliver it Friday evening, and prepare the payment from my business card.

The system can break this into a structured flow:

Run semantic product search.
Check inventory and current price.
Check delivery slot availability.
Create a payment intent.
Ask the user for confirmation.
Place the final order.

This is where AI becomes valuable.

Not because it replaces developers.

Because it turns messy human intent into structured backend operations.

When Dedicated Vector Databases Still Make Sense

PostgreSQL with pgvector is a great starting point for many Laravel applications.

It keeps the stack simple and keeps the data close to the domain model.

But dedicated vector databases are not going away.

Pinecone, Milvus, Qdrant, Weaviate, and similar systems can still make sense if you deal with very large vector datasets, advanced hybrid search, complex multi-tenant indexing, or an existing AI/search infrastructure.

In that case, Laravel can still remain the main application. The only difference is that your tool calls an external vector-store adapter instead of Eloquent.

The point is not “never use external vector databases.”

The point is:

Do not add another runtime, another service, and another deployment pipeline unless the product actually needs it.

Start simple.

Scale when the data proves you need to scale.

Production Checklist

AI in production is not only about prompts.

It is mostly about boring engineering.

And boring engineering is exactly what keeps AI features safe.

Use idempotency keys

Payment creation, booking holds, refunds, and trade intents must be idempotent.

If the model retries a tool call, the system should not create two payments, two bookings, or two stock orders.

Separate read tools from write tools

AI can have many read tools, but write tools should be limited.

Critical actions need explicit user confirmation.

Log every tool call

You should know what the user asked, what context was retrieved, what tool was selected, what input was sent, what output came back, what the model answered, and what action was finally executed.

This matters for debugging. In finance, healthcare, e-commerce, and other sensitive products, it matters even more.

Enforce Laravel policies

The AI agent must never become a permission bypass.

If the user cannot access a booking, invoice, account, payment, or trade manually, the AI should not access it either.

Queue expensive work

Embedding generation, document parsing, catalog reindexing, policy updates, and large sync jobs should run in queues.

Do not block the user because the system is rebuilding vectors.

Never trust RAG for real-time facts

RAG can retrieve policy context.

But real-time values must come from real systems:

Price comes from the Catalog API.
Availability comes from the Booking API.
Balance comes from the Banking API.
Fees come from the Brokerage API.
Payment state comes from the payment gateway.

Require confirmation for money movement

Payments, refunds, bank transfers, and stock purchases should always require explicit confirmation.

AI can prepare the action. The backend executes it. The user approves it.

What This Means for PHP Teams

For years, PHP developers heard the same story:

AI is Python territory.

PHP is for websites and CRUD.

If you want AI, build a Python service.

That story is outdated.

Modern PHP applications are not just templates and forms.

They run marketplaces, CRMs, fintech products, booking platforms, SaaS dashboards, internal tools, support systems, and high-volume APIs.

These are exactly the kinds of products where AI agents, RAG, semantic search, and workflow automation can create real value.

And many of those systems already live in Laravel.

So the AI layer should not automatically be outsourced to a separate Python bridge.

It should live where the business logic already lives.

When Python Still Belongs in the Architecture

Python still has an important role.

Use Python when you are training models, running notebooks, building custom ML pipelines, doing offline analytics, processing large data science workloads, experimenting with open-source models, or building specialized NLP and computer vision systems.

But do not use Python only because the industry got used to saying “AI equals Python.”

If all you need is LLM calls, embeddings, RAG, vector search, agents, tool calling, and business workflow orchestration, Laravel is now a serious option.

And in many product teams, it may be the cleaner option.

The Bottom Line

The future of AI in business applications is not a chatbot sitting somewhere beside the product.

The future is AI built directly into the workflows people already use.

In eCommerce, that means an assistant that understands product catalogs, inventory, return rules, and what the customer is actually trying to buy.

In booking platforms, it means an assistant that can read availability, pricing rules, cancellation policies, time slots, and user constraints before suggesting the next step.

In payments, banking, or brokerage products, it means AI that can explain failures, prepare safe actions, clarify intent, and support decisions without bypassing validation, permissions, or compliance.

That kind of AI does not need to live in a separate Python bridge by default.

It needs to live close to your models, policies, queues, APIs, transactions, logs, permissions, and users.

In other words, production AI needs to live inside the application layer where your business logic already works.

For PHP and Laravel teams, that changes the conversation.

One codebase.
One language.
One deployment pipeline.
One observability stack.
One place for business rules, permissions, and audit logs.
Zero unnecessary bridge services.

Kill the unnecessary Python bridge.

Not because Python is bad.

_But because production AI belongs where your product logic, user data, permissions, APIs, and business workflows already live.
_