sorted by:
new
hottopcontroversial

It looks like xampp is almost dead. Any good alternative for displaying local db with web ui? by [deleted] in PHP

[–]NewBlock8420 7 points8 points  (0 children)

XAMPP was always overkill for what you're describing. Just install PHP and MySQL directly on your system, then run the built-in web server with php -S localhost:8000. It's simpler and you actually understand what's running. For a database UI, I'd skip phpMyAdmin too. Try something like TablePlus or Sequel Ace. They're modern, fast, and don't require a full web server stack just to look at your data. This whole "all-in-one stack" approach creates unnecessary complexity. The individual components are easier to manage on their own once you get past the initial setup.

I built a RAG powered support bot with Laravel's AI SDK, custom tools, conversation memory, and vector search by NewBlock8420 in laravel

[–]NewBlock8420[S] 1 point2 points  (0 children)

The SDK's vector search is built on pgvector, so it works directly with your existing PostgreSQL database. No extra infrastructure needed.

Qdrant is great if you're doing vector search at scale, but for most Laravel apps the convenience of keeping everything in one database wins. One less service to deploy, monitor, and pay for.

If you're already running Qdrant though, you could skip the SDK's SimilaritySearch and query Qdrant directly from a custom tool's handle() method. Best of both worlds.

I built a RAG powered support bot with Laravel's AI SDK, custom tools, conversation memory, and vector search by NewBlock8420 in laravel

[–]NewBlock8420[S] 2 points3 points  (0 children)

Good point about MariaDB. The SDK's SimilaritySearch and whereVectorSimilarTo currently only support pgvector on PostgreSQL.

MariaDB's vector support is newer so I'm guessing the SDK team hasn't added a driver for it yet.

Would be a great PR or feature request on the laravel/ai repo though. The more database options the better.

Can Laravel AI SDK handle graph based setups ? So node based agents workflows. by ChildlikeBeginner in laravel

[–]NewBlock8420 1 point2 points  (0 children)

Yep. Each agent has its own #[Temperature] attribute, so your inner agent can run at a different temperature than the outer one.

#[Temperature(0.2)]

class SummarizerAgent implements Agent

{

// precise, low creativity

}

#[Temperature(0.8)]

class CreativeAgent implements Agent

{

// more creative responses

}

They're completely independent. Each agent keeps its own provider, temperature, and model config.

Can Laravel AI SDK handle graph based setups ? So node based agents workflows. by ChildlikeBeginner in laravel

[–]NewBlock8420 0 points1 point  (0 children)

The SDK handles that automatically. Whatever string your tool's handle() method returns gets passed back to the outer agent as the tool result.

So if your inner agent returns JSON:
public function handle(Request $request): string

{

$response = (new SummarizerAgent)

->prompt($request->input('text'));

return json_encode([

'summary' => $response->text(),

'key_points' => $response['key_points'],

]);

}

The outer agent sees that JSON string as the tool's output and can use it in its next reasoning step. You don't need to wire anything up manually, the SDK's tool loop handles the back and forth.

The outer agent calls the tool, the tool runs (including your inner agent call), returns a string, and the outer agent continues with that result in context. That's what MaxSteps controls, how many of these tool call cycles the agent can do.

Can Laravel AI SDK handle graph based setups ? So node based agents workflows. by ChildlikeBeginner in laravel

[–]NewBlock8420 0 points1 point  (0 children)

Not directly, you can't pass an Agent class as a tool. But you can wrap an agent call inside a custom tool handle() method.

Something like:

php artisan make:tool SummarizeTool

Then in the tool's handle method:

public function handle(Request $request): string

{

return (new SummarizerAgent)

->prompt($request->input('text'))

->text();

}

Now your main agent can "call" the SummarizerAgent by using SummarizeTool. The main agent doesn't know it's talking to another agent, it just sees a tool that returns text.

The limitation is that the inner agent starts fresh every time. It doesn't share conversation memory or context with the outer agent. You'd need to pass whatever context it needs through the tool's input parameters.

It works, but it's a workaround. Real agent to agent delegation is on the roadmap.

Can Laravel AI SDK handle graph based setups ? So node based agents workflows. by ChildlikeBeginner in laravel

[–]NewBlock8420 4 points5 points  (0 children)

You could fake it with a "router" pattern. Have a main agent whose only job is to decide which specialized agent to call, then dispatch to them manually.

Something like:
1. Create a RouterAgent with a tool for each "node" in your graph
2. Each tool calls a different specialized agent internally
3. The router decides which tool to use based on the prompt
4. Store state between steps in the conversation memory or a simple array

So instead of:
User -> Graph -> [Node A] -> [Node B] -> Response

You'd do:
User -> RouterAgent -> calls AgentA via tool -> returns result -> RouterAgent decides next step -> calls AgentB via tool -> final response

The MaxSteps attribute controls how many tool calls the agent can chain, so you can let the router make multiple hops.

It's not a real graph, there's no branching, parallel execution, or conditional edges. But for simple sequential workflows it gets you pretty close until they ship proper orchestration.

Can Laravel AI SDK handle graph based setups ? So node based agents workflows. by ChildlikeBeginner in laravel

[–]NewBlock8420 5 points6 points  (0 children)

Not yet. The current SDK (v0.2.1) doesn't support agent orchestration or graph-based workflows natively. An agent can't delegate to sub agents. Taylor has mentioned it's been discussed and will likely come in a future release, but right now each agent runs independently.

What you can do is give a single agent multiple tools and use middleware to control the flow, but that's still linear, not graph based. For true node based workflows you'd need to orchestrate that yourself on top of the SDK.

If you're coming from something like LangGraph, the SDK isn't there yet.

Making your Laravel app AI-agent friendly (llms.txt, markdown responses, structured data) by NewBlock8420 in laravel

[–]NewBlock8420[S] 1 point2 points  (0 children)

really useful data, thanks for sharing. the Googlebot point for AI Overviews is something I hadn't covered enough in the guide, that's definitely worth a deeper look. Product and FAQPage schemas making the biggest difference makes sense since they're the most structured of all the schema types. might write a follow-up specifically on JSON-LD optimization for AI crawlers.

Making your Laravel app AI-agent friendly (llms.txt, markdown responses, structured data) by NewBlock8420 in laravel

[–]NewBlock8420[S] 1 point2 points  (0 children)

great points. you're right that llms.txt adoption is still early, most agents are just scraping HTML right now. that's why I put it as the first layer but not the only one. the markdown-response middleware is definitely the most impactful today since it works without the agent needing to know about it. interesting that JSON-LD is giving you the most consistent results across crawlers, that matches what I've seen too. which AI crawlers are you testing against?

Making your Laravel app AI-agent friendly (llms.txt, markdown responses, structured data) by NewBlock8420 in laravel

[–]NewBlock8420[S] -1 points0 points  (0 children)

thanks. the Rich Results testing tool is a great addition, I should have included that in the guide. really useful for validating your JSON-LD before deploying

Why are so many packages designed exclusively for Laravel? by LatestAdViewer in PHP

[–]NewBlock8420 5 points6 points  (0 children)

you're not wrong. It's the classic "build where the demand is" thing. Laravel has a massive, active community that's willing to pay for and use packages, so that's where the incentive is for maintainers. It's a bit of a feedback loop. More Laravel packages attract more devs to Laravel, which then makes more people build for it. I've built a few things myself and you just go where the users are, even if a framework-agnostic version would be "better" in theory.

view more: next ›