The idea essentially revolves around the fact that whether the AI-powered search mentions your website in its answer or not or whether it cites your website as a source or not, and lastly, compare these resulst with the regular Google search results.

Does your website show up when AI-powered search answers questions related to the topics it covers?

When you search something on a search engine, you get a list of results. And based on that you can decide the ranking of your website. That’s not true with the AI-generated answers. Because these answers are generated based on the information available on the web and the AI model’s understanding of the topic.

So, if your website is not mentioned in the answer or cited as a source, it can be difficult to know whether your website is visible to the AI model or not.

In this tutorial, we’ll build a small AI search visibility analyzer tool in JavaScript to tackle the above challenge. The tool can accept a domain and multiple queries, call Google AI Mode and regular Google search through SearchApi, and compare the two responses.

• What we’re going to build
• Prerequisites
• The application architecture
• Calling SearchApi from the backend
• Understanding the two response shapes
• Turning AI Mode into readable answer text
• Normalizing the target domain
• Detecting AI answer mentions
• Inspecting AI references
• Comparing regular Google results
• Returning a stable application response
• Running both searches for a query
• Building the form
• Running the application
• Taking this further
• In closing

If you’ve read my previous article, you would know that the project was about giving a terminal-based application a real-time web-search capability. This project uses that same premise to inspect how AI-search results are presented to users.

The finished application will be built around the following architecture.

What we’re going to build

Our AI search visibility analyzer has 2 inputs.

• A domain, such as css-tricks.com.
• A list of queries, one query per line.

For every query, it’ll show the following information:

• The Google AI Mode answer.
• Whether the target domain is mentioned in that answer.
• The sources cited by AI Mode.
• Other domains appearing in those citations.
• Regular Google’s organic search results.
• Whether the target domain appears in those results.
• The best organic position when Google provides one.

The tool intentionally doesn’t give a single “AI visibility score” here.

That’s because being mentioned in an answer or being cited as a source or appearing in an organic result can be related, but they are essentially not the same thing. A single number out of these would be misleading and would not make any sense.

On top of this, it’s also a one-time analyzer. It does not store runs, draw historical charts, or schedule recurring checks. These features can be enhancements for the next iteration of the project.

Prerequisites

To build the project, you will need…

• Node.js 20 or later installled on your machine.
• A SearchApi API key.
• A browser to run the frontend.

Create a project and initialize it with npm.

mkdir ai-analyzer
cd ai-analyzer
npm init -y

The project uses Node’s built-in fetch, HTTP server, test runner, and environment-file support. So, you do not need to install any additional dependencies.

Next, we’ll create a .env file at the project root and add our SearchApi API key.

SEARCHAPI_API_KEY="your_searchapi_api_key"

This API key will stay on the server. We’re not placing it in client-side JavaScript or sending it back in an API response. That could be a security hazard.

The application architecture

The application has a small Node.js backend and a static frontend and the entire package could be summarized like so.

Browser
  → POST /api/analyze
      → validate domain and queries
      → call Google AI Mode
      → call regular Google
      → normalize provider responses
      → compare domains and aggregate signals
Server
  ← return a stable application response

We’re keeping the SearchApi-specific details out of the UI.

SearchApi returns different data for AI Mode and regular Google search results. And so, in the backend, we’re turning those responses into a simple format that the frontend can understand.

So, the project is split into the following few small pieces/modules:

• server.mjs - The entry point of the application. It handles the HTTP server and routes.
• src/searchapi.mjs - Handles the SearchApi calls for both Google AI Mode and regular Google search.
• src/analysis.mjs - Handles the analysis logic to compare the AI Mode and regular Google search results.
• public/ - Contains the static frontend files.
• test/ - Contains the test files for the backend modules.

Calling SearchApi from the backend

The SearchApi request pattern is the same one I used in the previous article, which is to construct a URL, add the engine and query, and send the API key as a bearer token.

Here, we’ll be using two SearchApi engines to fulfill our requirements.

• google_ai_mode
• google

We kept the SearchApi calls in their own module so the rest of the application doesn’t have to worry about how the requests are made.

Here’s what the module looks like.

const endpoint = "https://www.searchapi.io/api/v1/search";

export async function searchApi({
  engine,
  query,
  apiKey,
  fetchImpl = fetch,
  timeoutMs = 30_000,
}) {
  if (!apiKey) {
    throw new Error("SEARCHAPI_API_KEY is not configured.");
  }

  const url = new URL(endpoint);
  url.searchParams.set("engine", engine);
  url.searchParams.set("q", query);

  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), timeoutMs);

  try {
    const response = await fetchImpl(url, {
      headers: {
        Authorization: `Bearer ${apiKey}`,
        Accept: "application/json",
      },
      signal: controller.signal,
    });

    if (!response.ok) {
      throw new Error(`SearchApi returned ${response.status}.`);
    }

    return await response.json();
  } finally {
    clearTimeout(timer);
  }
}

export const searchAiMode = (options) =>
  searchApi({ ...options, engine: "google_ai_mode" });

export const searchGoogle = (options) =>
  searchApi({ ...options, engine: "google" });

As you can tell, we’re using URL and searchParams to construct the request rather than concatenating the query into the URL ourselves. This takes care of encoding things like spaces and punctuation.

Since we’re dealing with an external API, we also added a timeout to the request. If the request takes longer than 30 seconds, it will be aborted and an error will be thrown.

Understanding the two response shapes

The Google AI Mode and the regular Google Search returns different response structures. So, we need to handle them a little differently.

For instance, the following fields can be returned in the AI mode response:

• text_blocks - An array of text blocks that make up the answer. Each block can be a string or an object with an answer field and an optional items array.
• markdown - A string containing the answer in Markdown format.
• reference_links - An array of links to the sources cited by the answer.
• web_results - An array of additional web results.

On the other hand, the regular Google Search returns organic_results for the usual search listings.

I didn’t want the application to deal with all these different fields itself and so, I created a normalization function for both the response types to extract the relevant information and return back it in one consistent format.

function normalizeWebResults(response) {
  const results =
    response?.organic_results ??
    response?.web_results ??
    [];

  return (Array.isArray(results) ? results : [])
    .map(normalizeLink)
    .filter((item) => item.link || item.title || item.snippet);
}

Here, we’re falling back to web_results because AI Mode can also return web results. We’re not treating the two response formats as identical. We’re just extracting the parts that the analyzer needs into a common format.

Also, these fields are optional. That is because a query might not return any references or organic results, and that’s quite different from the request failing itself. So, we need to handle the case where these fields are missing and return an empty array instead of throwing an error.

Turning AI Mode into readable answer text

We’re using SearchApi’s text_blocks instead of the markdown field because the markdown field can contain citation links and reference markers that don’t look great when simply printed on the page.

For the first version, I decided to extract the actual text from text_blocks instead like so.

function answerText(response) {
  const blocks = Array.isArray(response?.text_blocks)
    ? response.text_blocks
    : [];

  const text = blocks
    .map((block) => {
      if (typeof block === "string") {
        return block;
      }

      const parts = [
        block?.answer,
        ...(Array.isArray(block?.items)
          ? block.items.map((item) => item?.answer)
          : []),
      ];

      return parts.filter(Boolean).join("\n");
    })
    .filter(Boolean)
    .join("\n\n");

  return text || response?.markdown || "";
}

As you can tell, we’re iterating through the text_blocks array and extracting the answer field from each block. If a block has an items array, we’re also extracting the answer field from each item in that array.

Lastly, we’re joining all the extracted answers with two newlines to create a readable answer text. If for some reason, there are no text_blocks, we’re falling back to the markdown field.

Normalizing the target domain

Before comparing the results, we need to make sure the domain entered by the user is in a consistent format. For instance, the following URLs should point to the same target.

css-tricks.com
https://css-tricks.com
https://www.css-tricks.com/some-page

So instead of comparing the full URLs, we’re extracting the hostname and using that for the comparison.

export function normalizeDomain(value) {
  const input = String(value ?? "").trim();

  if (!input) {
    throw new Error("Enter a domain.");
  }

  const candidate = /^https?:\/\//i.test(input)
    ? input
    : `https://${input}`;

  let hostname;

  try {
    hostname = new URL(candidate)
      .hostname
      .toLowerCase()
      .replace(/^www\./, "");
  } catch {
    throw new Error("Enter a valid domain, such as example.com.");
  }

  if (
    !hostname ||
    hostname.includes(" ") ||
    !hostname.includes(".") ||
    hostname.startsWith(".") ||
    hostname.endsWith(".")
  ) {
    throw new Error("Enter a valid domain, such as example.com.");
  }

  return hostname;
}

As you can see, we’re also not treating every subdomain as the same domain. blog.example.com and example.com might be two different properties, and so we want to keep them separate. The only exception is the www subdomain, which is treated as the same as the root domain.

Detecting AI answer mentions

When you work with AI-generated answers, there are two possibilities. Either the answer mentions a website as a useful resource or it cites a website as one of its sources.

Here, we’re using a simple string check to if the answer mentions the target domain or not.

const answer = answerText(aiResponse);

const mentionedDomain = answer
  .toLowerCase()
  .includes(targetDomain);

As you can tell, we’re converting both the answer and the target domain to lowercase before checking for a mention. This makes the check case-insensitive.

Inspecting AI references

Next, we’re normalizing the AI Mode references so that we can work with them in the same way throughout the application using a normalizeLink function.

function normalizeLink(item) {
  const link = typeof item?.link === "string"
    ? item.link
    : undefined;

  return {
    title: item?.title || undefined,
    link,
    hostname: hostnameFromUrl(link),
    source: item?.source || undefined,
    snippet: item?.snippet || undefined,
    displayedLink: item?.displayed_link || undefined,
    position: Number.isFinite(item?.position)
      ? item.position
      : undefined,
    index: Number.isFinite(item?.index)
      ? item.index
      : undefined,
  };
}

Here, we’re extracting the hostname from the link so that we can compare it with the target domain. We’re also normalizing other fields like title, source, and snippet to make sure they are either strings or undefined.

Once the references are in this format, checking whether the target domain was cited is quite straightforward. We just check if any of the normalized references have a hostname that matches the target domain like so.

const citedTarget = references.some(
  (reference) => reference.hostname === targetDomain
);

One thing I noticed while working with the references is that some Google links can be redirects rather than direct links to the original page. So, when SearchApi can’t resolve one of those links, we keep the URL as it is instead of trying to guess where it points.

Comparing regular Google results

The regular Google search gives us the traditional organic results, so we can use those to check whether the target domain appears there and if so, what its best position is.

const results = normalizeWebResults(googleResponse);

const matchingResults = results.filter(
  (result) => result.hostname === targetDomain
);

const bestPosition = matchingResults
  .map((result) => result.position)
  .filter(Number.isFinite)
  .sort((a, b) => a - b)[0];

If Google gives us a position result, we’re showing it in the UI. If in case it doesn’t, we just report that the domain was found in the results.

At this point, we have three visibility pointers for the target domain.

1. Mentioned in answer
2. Cited in AI references
3. Found in organic results

Keeping these pointers separate is important. For instance, a domain can appear in the organic results without being mentioned in the AI answer. It can also be cited by AI Mode without appearing near the top of the organic results. And sometimes, it can be mentioned in the answer without being one of the cited sources.

And so, we want to keep these three pointers separate in the analyzer rather than combining them into a single score as said earlier.

Returning a stable application response

The application doesn’t send the raw SearchApi responses back to the browser as it is. We’re building and returning a smaller response from the backend so frontend only receives the information it needs to display the results.

For a single query, the response looks something like so.

{
  query: "best CSS blog",
  status: "success",
  aiMode: {
    answerText: "...",
    mentionedDomain: false,
    references: [],
    otherDomains: ["example.com"]
  },
  google: {
    results: [],
    foundDomain: false,
    otherDomains: []
  }
}

We also return a summary for the whole run.

{
  targetDomain: "css-tricks.com",
  analyzedAt: "2026-09-23T10:00:00.000Z",
  summary: {
    totalQueries: 3,
    successfulQueries: 3,
    failedQueries: 0,
    answerMentionCount: 1,
    aiReferenceCount: 1,
    regularResultCount: 2,
    referencedDomains: ["smashingmagazine.com"]
  },
  queries: []
}

We’re creating this succinct response structure so the frontend doesn’t need to know anything about the underlying API responses and the results stay consistent.

Running both searches for a query

For each query, we need to make two SearchApi requests: one to Google AI Mode and one to regular Google search. Since they’re independent of each other, we can run them in parallel like so.

const [ai, google] = await Promise.allSettled([
  searchAiMode({
    query,
    apiKey: process.env.SEARCHAPI_API_KEY,
  }),
  searchGoogle({
    query,
    apiKey: process.env.SEARCHAPI_API_KEY,
  }),
]);

As you can tell, we’re using Promise.allSettled() here instead of Promise.all() because we don’t want one failed request to hamper the other result. If AI Mode succeeds but regular Google search fails, we can still show the AI Mode result and mark the query as partial. And vice versa.

If both requests fail, we mark the query as an error.

We’re also limiting each run to ten queries. Since each query makes two SearchApi requests, that gives us a predictable maximum of 20 requests per run, keeping the interface reasonably fast.

Building the form

The frontend for this application is intentionally simple. It only needs a domain, a list of queries, and a button to start the analysis. And That’s it.

<form id="analyze-form">
  <label for="domain">Domain</label>
  <input
    id="domain"
    name="domain"
    type="text"
    placeholder="example.com"
    required
  />

  <label for="queries">Queries</label>
  <textarea
    id="queries"
    name="queries"
    rows="6"
    placeholder="best CSS blog
best UI blog"
    required
  ></textarea>

  <button type="submit">Analyze visibility</button>
</form>

When the form is submitted, the browser sends the input to the backend like so.

const response = await fetch("/api/analyze", {
  method: "POST",
  headers: {
    "content-type": "application/json",
  },
  body: JSON.stringify({
    domain: form.domain.value,
    queries: form.queries.value,
  }),
});

Once the response comes back, the UI shows a summary followed by a result card for each query. Each card contains the AI answer, its references, the organic results, and the three visibility signals we’ve been tracking.

For the first version, I kept everything visible without introducing a complicated dashboard. If I were to turn this into a larger product, I’d probably collapse long answers and source lists behind expandable sections. You get the idea.

Running the application

Start the app:

npm start

Then open http://localhost:3000 and enter a domain along with a few queries.

For example…

Domain: css-tricks.com

Queries:
best css blog
css property almanac
css guides

Once the analysis finishes, you’ll get the AI Mode answer, its references, the regular Google search results, and the three visibility signals for each query.

One thing to keep in mind is that these are live search results. The exact wording of a query, location, language, timing, and other search conditions can affect what comes back. So, this tool is best thought of as a snapshot of what the search surfaces returned at that time, rather than a permanent ranking report.

Here’s what the input screen looks like.

And here’s the results screen.

If you want to try it yourself, the complete source is available on GitHub. Fork it, add your SearchApi API key in the .env file, and you’re ready to go.

Taking this further

We intentionally kept the first version of this little tool small, but there’s definitely room for growth. We could store runs and track changes over time, add scheduled checks and alerts, or compare multiple domains. It could also be extended to support other search engines and AI-powered search tools.

Things like DB persistence, timestamps, query versioning, etc. are a few good candidates for a future article to cover, but for now, I think this is a good starting point to understand how your website is visible in the world of AI-powered search with as little as possible.

In closing

We built this POC to explore what does a website’s visibility look like when search starts generating answers instead of just showing links.

Our little tool gives us a way to look at that question without reducing everything to a single score. For each query, we can see whether a domain was mentioned in the AI answer, cited as a source, or appeared in the regular search results.

And even though it’s a small tool, it makes the difference between traditional search and AI-powered search much easier to see and understand while still being useful.

In this article, I want to highlight 7 of these features that I think are game-changing and that you can start using today (of course, in some of the modern browsers).

• CSS Text Box
• CSS Scrollspy
• Contrast Color
• The hidey bar using @scroll-state query
• Gap Decorations
• The light-dark() function
• The linear() function

CSS Text Box

A new property called text-box is coming to the web platforms that allows you to trim extra leading and verical whitespace above and below the text glyphs, enabling precise pixel-perfect alignment and typgraphy layouts without arbitrary negative margins.

The short-hand for the text-box property:

text-box: trim-both cap alphabetic;

The long-hand version of the text-box property:

text-box-trim: trim-start | trim-end | trim-both | none;
text-box-edge: cap | ex | text | leading + alphabetic | text;

As you can tell, the text-box property has two parts. The first part is the text-box-trim property which controls how the text box is trimmed. The second part is the text-box-edge property which controls which edge of the text box is used for alignment.

This is essentially useful for when you want to align text with other elements on the page and you don’t want to use negative margins or padding to do so.

The following CodePen demonstrates how this looks like in action.

See the Pen Interactive CSS text-box by web.dev (@web-dot-dev) on CodePen.

In real world, this can be useful in scenarios where the extra leading and vertical whitespace above and below the text glyphs can cause misalignment with other elements on the page. Take this for instance.

As you can tell, with the text-box property, we are able to align the text with the image quite nicely without having to use negative margins or padding.

Read more

CSS Scrollspy

Another interesting new property called scroll-target-group can be used to create a scrollspy effect on a page. So, if you don’t know what a scrollspy effect is, it’s a web design UI pattern where navigation links or table-of-contents items automatically update and highlight in real time based on the section of the page currently visible in the user’s viewport.

To implement this, you will need to have a list of navigation links or table-of-contents items that are possibly combined under an element like <ol> or <ul>. And these navigation links are tied to the sections of the page that they represent using the href attribute. The sections of the page are marked with an id attribute that matches the href attribute of the navigation links.

Something like this.

<ol id="toc">
  <li><a href="#section1">Section 1</a></li>
  <li><a href="#section2">Section 2</a></li>
  <li><a href="#section3">Section 3</a></li>
</ol>

<section id="section1">
  <h2>Section 1</h2>
  <p>Content for section 1...</p>
</section>
<section id="section2">
  <h2>Section 2</h2>
  <p>Content for section 2...</p>
</section>
<section id="section3"> 
  <h2>Section 3</h2>
  <p>Content for section 3...</p>
</section>

Now, we can implement the scrollspy effect using the scroll-target-group property like so.

ol {
  background-color: gray;
  right: 10px;
  top: 10px;
  position: fixed;
  scroll-target-group: auto;
}

a:target-current {
  color: red;
}

section {
  background: lightgray;
  height: 60vh;
  margin: 10px;
}

Here’s how it looks like in action.

See the Pen CSS Scrollspy by Amit Merchant (@amit_merchant) on CodePen.

This property unlocks a lot of possibilities for creating scrollspy effects without having to rely on JavaScript. You can also use this property to create other interesting effects like highlighting the current section in a table-of-contents, or even creating a progress bar that fills up as the user scrolls through the page.

Read more

Contrast Color

Have you ever been in a situation where you have a background color and you want to set the text color to be readable against that background color and you’re not sure what color to use for your text? Well, the new contrast-color() function in CSS can help you with that.

The function takes a valid CSS color value as an argument and returns a color that has sufficient contrast against this color. This is useful for ensuring that your text is readable against different background colors.

color: contrast-color(purple);
/* Returns: white */

color: contrast-color(yellow);
/* Returns: black */

color: contrast-color(var(--brand-color));
/* Returns: whichever of black or white has higher contrast */

Here’s a CodePen to demonstrate how this works.

See the Pen contrast-color() by Amit Merchant (@amit_merchant) on CodePen.

Hover over the boxes to see how the text color changes dynamically based on the background color. The contrast-color() function ensures that the text is always readable against the background color.

Read more

The hidey bar using @scroll-state query

A new type of CSS scroll-state media query is coming to the web platform that allows you to create a hidey bar effect on your website. This is useful for creating a navigation bar that hides when the user scrolls down and shows when the user scrolls up.

Here’s how that works.

html {
  container-type: scroll-state;
}

header {
  position: fixed;
  inset: 0 0 auto;
  transition: translate 0.25s;
  translate: 0 0;

  /* Slide header up when last having scrolled towards the bottom */
  @container scroll-state(scrolled: bottom) {
    translate: 0 -100%;
  }
}

As you can tell, first, we set the container-type property to scroll-state on the html element. This allows us to use the @container rule to query the scroll state of the container.

Next, we set the position property of the header element to fixed and set the inset property to 0 0 auto. This positions the header at the top of the viewport.

Then, we set the transition property to translate 0.25s to smoothly animate the translation of the header when it hides and shows.

Finally, we use the @container rule to query the scroll state of the container. When the user scrolls down, we translate the header up by setting the translate property to 0 -100%. When the user scrolls up, we translate the header back down by setting the translate property to 0 0.

Here’s a CodePen to demonstrate how this works.

See the Pen Hidey Bar Demo (Hide on Scroll Down, Show on Scroll Up // Scroll State Queries) by Bramus (@bramus) on CodePen.

Read more

Gap Decorations

CSS Gap Decorations allow you to draw visual lines (dividers) between items in a Flexbox or CSS Grid layout using native CSS properties, eliminating the need for extra HTML elements or complex CSS workarounds.

Previously, styling gaps between layout items required workaround solutions, such as adding extra <div> elements, setting outer borders, or applying pseudo-elements (::before / ::after).

These workarounds had several drawbacks:

• Cluttered Markup: Required adding unnecessary HTML elements solely for visual presentation.
• Accessibility Issues: Unnecessary decorative elements cluttered screen reader output.
• Maintenance Overhead: Complex geometric calculations were needed to prevent unwanted border overlaps.

With gap decorations, you can directly style gaps in Grid and Flexbox containers:

• column-rule: Styles vertical gap lines between columns.
• row-rule: Styles horizontal gap lines between rows.
• rule: A shorthand property that applies styles to both row and column gaps simultaneously.

And here’s an example of how to use it.

.container {
  display: flex;
  column-rule: 2px dashed #ccc; /* Adds a dashed divider between columns */
  row-rule: 1px solid #ddd;    /* Adds a solid divider between rows */
}

Here’s a simple CodePen to demonstrate how this works.

See the Pen Gap Decorations by Amit Merchant (@amit_merchant) on CodePen.

Read more

The light-dark() function

A really nice addition to the CSS color functions is the light-dark() function which is also now widely supported across all modern browsers. This function allows you to define a color that adapts to the user’s preferred color scheme (light or dark mode).

For this function to work, you first need to define color-scheme property on the html element like so.

html {
  color-scheme: light dark;
}

What this does is it tells the browser that your website supports both light and dark color schemes. Now, you can use the light-dark() function to define colors that the browser will automatically switch between based on the user’s preferred color scheme.

.card {
  background-color: light-dark(
    #fff, /* Light mode color */
    #000  /* Dark mode color */
  );
  color: light-dark(#000, #fff);
}

And recently, the light-dark() function has been updated to also accept images, where instead of defining a color for light and dark mode, you can define an image for light and dark mode.

.card {
  background-image: light-dark(
    url('light-mode-image.jpg'), /* Light mode image */
    url('dark-mode-image.jpg')  /* Dark mode image */
  );
}

Read more

The linear() function

If you’ve ever wanted to implement natural, physics-based easing animations (such as bouncy or spring-like effects) without relying on heave JavaScript animation libraries, the new linear() function in CSS is here to help.

This function allows you to create animations that mimic real-world physics, making your UI feel more dynamic and responsive.

So, traditional CSS easing functions like ease-in-out or standard cubic beziers cannot produce overshoot or spring-like bouncing effects because they are constrained to simple curve control points.

On the other hand, The linear() function accepts an unlimited series of comma-separated stop values (typically between 0 and 1, though values can overshoot above 1 or go below 0 to create bounces).

By specifying multiple key points along a timeline, developers can approximate realistic physical properties such as mass, stiffness, damping, and velocity to simulate natural motion.

Here’s an example of how to use the linear() function to create a bouncy animation.

.dialog {
  /* Approximates a spring/bounce effect using linear() stop points */
  animation-timing-function: linear(
    0, 0.218 2.1%, 0.862 6.5%, 1.114 10.2%, 1.2 13%, 
    1.187 16%, 1.018 24.2%, 0.98 29%, 1.002 42.8%, 1
  );
}

And a little CodePen to demonstrate how this works.

See the Pen The linear() function by Amit Merchant (@amit_merchant) on CodePen.

Read more

Ask an LLM about a programming concept and it can probably answer from its existing knowledge. Ask it about the latest JavaScript frameworks, today’s news, or the current price of a product, and its answer may be outdated.

One way to solve this is to give the model a tool or capability that can search the web before concluding its answer. A form of Retrieval-Augmented Generation (RAG) technique.

You might have already seen this pattern in modern AI assistants. For instance, here’s what it looks like in Gemini.

In this concise tutorial, we’ll build something similar but slightly bare-bones. A small AI agent in JavaScript that can decide when it needs to search the web, use SearchApi to retrieve Google search results, and then use those results to formulate its answer.

$ node agent.js "What are the latest developments in PHP 8.5?"

🤖 Thinking...

🔎 Searching the web for: "PHP 8.5 latest developments release"
📄 Found 5 results.

🤖 Thinking...
...

As you can tell, if the question requires a web search, the agent will perform the web search and then use the results to answer the question/prompt.

• What Makes Something an AI Agent?
• What We’re Going to Build
• Prerequisites
• Connecting to the LLM
• Give the AI a Search Tool
• Implement search_web() with SearchApi
• The Agent Loop
• Run the Agent
• Why This Is an Agent
• Taking the Agent Further
• In Closing

What Makes Something an AI Agent?

Before we dive into building our AI agent, let’s quickly understand what makes something an AI agent.

So, a regular LLM would typically take a prompt and generate a response based on its training data. Meaning, the response you get might be outdated or not relevant to the current context and that’s not ideal when you’re looking for up-to-date information.

User → LLM → Answer

On the other hand, an LLM with a tool can take a prompt, decide if it needs to use a tool (like a web search), use that tool to get real-time information, and then generate a response based on that information. If the tool is not needed, it can just generate a response based on its training data.

User → LLM → Tool → Result → LLM → Answer

The important distinction here is that the LLM doesn’t execute the tool itself. It decides that a tool is needed and generates a structured tool call. Our application executes the function and sends its result back to the model.

For instance, OpenRouter (the API gateway for LLMs), which we are going to use in this tutorial, exactly describes this as tool calling. It essentially gives an LLM access to external tools.

And this leads us to the agent loop. The agent loop is a process where the LLM can decide to use a tool, get the result, and then decide if it needs to use another tool or generate a final answer. This loop continues until the LLM decides it has enough information to answer the user’s question.

An agent doesn’t have to be a complicated framework. At its simplest, it’s an LLM, a set of tools, and a loop that allows the model to act on the results.

OpenRouter’s own documentation calls this a simple agentic loop.

What We’re Going to Build

Like I said previously, we’re going to build a small AI agent in JavaScript that can decide when it needs to search the web, use SearchApi to retrieve Google search results, and then use those results to formulate its answer. The flowchart of our agent looks like this.

Let’s address all the jargon in the flowchart above so that we understand what all the components do.

• Nemotron — It’s one of OpenRouter’s free LLMs that decides whether it needs to search and what query to use.
• JavaScript — Orchestrates the agent and executes tools.
• SearchApi — Retrieves real-time Google search results.
• Agent loop — Feeds tool results back into the LLM.

With that out of the way, let’s get started with building our AI agent.

Prerequisites

To build this AI agent, you’ll need the following:

• Node.js 20+
• An OpenRouter API key
• A SearchApi API key

Once you have these, run the following commands to create a new Node.js project and install the required dependencies.

mkdir web-search-agent
cd web-search-agent
npm init -y
npm install openai dotenv

Now, create a .env file in the root of your project and add your OpenRouter and SearchApi API keys like so.

OPENROUTER_API_KEY=your_openrouter_api_key
SEARCHAPI_API_KEY=your_searchapi_api_key

For this tutorial, I’m using OpenRouter’s Nemotron 3.5 Lightning model, which is a free model that has the capability to decide when it needs to search the web and what query to use. You can use any other model that has the same capability, but for this tutorial, we’ll stick with Nemotron.

Also, you get a free SearchApi API key that allows you to make 100 requests, which is more than enough for this tutorial. If you need more, you can upgrade to a paid plan.

Connecting to the LLM

Create a new file called agent.js in the root of your project and add the following code to connect to the OpenRouter API.

import "dotenv/config";
import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://openrouter.ai/api/v1",
  apiKey: process.env.OPENROUTER_API_KEY,
});

As discussed previously, we’re using OpenRouter’s API to connect to the Nemotron model.

const MODEL = "nvidia/nemotron-3.5-lightning:free";

Give the AI a Search Tool

Next, we need to give the AI a tool that it can use to search the web. For this, we need a tool definition.

const tools = [
  {
    type: "function",
    function: {
      name: "search_web",
      description:
        "Search the web for current information. Use this when the user asks about recent, current, or up-to-date information.",
      parameters: {
        type: "object",
        properties: {
          query: {
            type: "string",
            description: "The search query to send to Google.",
          },
        },
        required: ["query"],
      },
    },
  },
];

Notice, we’re not giving the LLM the implementation of search_web(). We’re giving it a description of what the function does and the parameters it accepts.

The model can then generate:

{
  "type": "function",
  "index": 0,
  "id": "call-03f0d876-015c-403e-b2de-3f28973dacc1",
  "function": {
    "name": "search_web",
    "arguments": {
      "query": "latest JavaScript frameworks 2026 trends web development"
    }
  }
}

OpenRouter’s documentation uses the same pattern: define a function schema, receive tool_calls, execute the requested function in your application, and return the result to the model.

Implement search_web() with SearchApi

Next, we need to implement the search_web() function that will use SearchApi to retrieve Google search results.

async function searchWeb(query) {
  console.log(`\n🔎 Searching the web for: "${query}"`);

  const url = new URL("https://www.searchapi.io/api/v1/search");

  url.searchParams.set("engine", "google");
  url.searchParams.set("q", query);

  const response = await fetch(url, {
    headers: {
      Authorization: `Bearer ${process.env.SEARCHAPI_API_KEY}`,
    },
  });

  if (!response.ok) {
    const error = await response.text();

    throw new Error(
      `SearchApi request failed (${response.status}): ${error}`
    );
  }

  const data = await response.json();

  /*
   * We don't need to send the entire SearchApi response
   * back to the LLM. Extract the useful organic results.
   */
  const results = (data.organic_results || [])
    .slice(0, 5)
    .map((result) => ({
      title: result.title,
      link: result.link,
      snippet: result.snippet,
    }));

  console.log(`📄 Found ${results.length} results.`);

  return results;
}

Why SearchApi? An AI agent needs a reliable way to access fresh information from the web. SearchApi provides structured search results through an API, so we can expose web search as a tool without having to build or maintain our own scraping infrastructure. That makes it a natural fit for an agent that needs to ground its answers in current web data.

The Agent Loop

Lastly, we need to build the agent loop that will allow the LLM to decide when it needs to search the web and when it has enough information to answer the user’s question.

async function runAgent(userQuestion) {
  const messages = [
    {
      role: "system",
      content:
        "You are a helpful research assistant. Use the search_web tool whenever you need current information. After receiving search results, use them to answer the user's question. Mention the sources you used by including their URLs.",
    },
    {
      role: "user",
      content: userQuestion,
    },
  ];

  /*
   * The agent can go through multiple tool calls.
   *
   * For example:
   *
   * LLM → search_web()
   *     → search_web()
   *     → final answer
   */
  for (let i = 0; i < 5; i++) {
    console.log(`\n🤖 Thinking...`);

    const response = await client.chat.completions.create({
      model: MODEL,
      messages,
      tools,

      /*
       * We don't need the model's reasoning output for this demo.
       */
      reasoning: {
        exclude: true,
      },
    });

    const message = response.choices[0].message;

    /*
     * Add the assistant's response to the conversation.
     */
    messages.push(message);

    // No tool call means the agent has its final answer.
    if (!message.tool_calls?.length) {
      return message.content;
    }

    /*
     * Execute every tool requested by the AI.
     */
    for (const toolCall of message.tool_calls) {
      if (toolCall.function.name === "search_web") {
        const { query } = JSON.parse(toolCall.function.arguments);

        const results = await searchWeb(query);

        messages.push({
          role: "tool",
          tool_call_id: toolCall.id,
          content: JSON.stringify(results),
        });
      }
    }
  }

  throw new Error("Agent reached the maximum number of tool calls.");
}

As you can tell, the user prompts the agent with a question. The code then checks if the model requested the tool.

if (!message.tool_calls?.length) {
  return message.content;
}

If so, it extracts the arguments from the tool call.

const { query } =
  JSON.parse(toolCall.function.arguments);

Then, it executes the search_web() function and sends the results back to the model.

const results = await searchWeb(query);

And finally, it adds the tool’s response to the conversation.

messages.push({
  role: "tool",
  tool_call_id: toolCall.id,
  content: JSON.stringify(results),
});

Ask the LLM again, and it will either request another tool call or provide its final answer. And that’s how the agent loop works.

This maps almost exactly to OpenRouter’s documented three-step tool-calling flow and its simple agentic loop.

Run the Agent

Add the following piece of code to take a question from the command line and run the agent.

/*
 * Run the agent.
 */

// eg. "What are the latest JavaScript frameworks for building websites in 2026?"
const question = process.argv.slice(2).join(" ");

if (!question) {
  console.error('Usage: node agent.js "your question"');
  process.exit(1);
}

console.log(`\n👤 User: ${question}`);

try {
  const answer = await runAgent(question);

  console.log("\n\n💬 Agent:\n");
  console.log(answer);
} catch (error) {
  console.error("\n❌ Error:");
  console.error(error);
}

Now, you can run the agent with a question like so.

$ node agent.js "Who won the nobel prize in chemistry 2025?"

The workflow of the agent will look like this.

The same way, you can ask a different question. For instance…

$ node agent.js "What are the best developer laptops available right now?"

And the agent will search the web and provide an answer based on the latest information.

If you just want to see the project in action, you can check out the GitHub repository. Fork it, add your OpenRouter and SearchApi API keys in the .env file, and you’re good to go.

Why This Is an Agent

You might be wondering, “Amit! Isn’t this just an LLM calling an API?”

Well, no.

The key difference is that the thing we built here can interpret a natural-language request, decide whether it needs external information, select a tool, generate the tool’s arguments, consume the tool’s result, and then produce a final response.

And most importantly, we didn’t tell it when to search or exactly what query to send. We gave it a capability and let the model decide how to use that capability.

Taking the Agent Further

As for taking this agent further, you can, for instance, make the agent do multiple searches and combine the results to answer a question.

Let’s say the user asks, “Compare Astro, Next.js, and Nuxt for building a content-heavy website.” The agent could search each technology independently and synthesize the results.

You can also utilize SearchApi’s broader API offering that gives you opportunities to add specialized capabilities around things like shopping, Maps, News, YouTube, and other search engines/data sources.

So your agent could evolve from:

search_web()

into:

search_web()
search_news()
search_shopping()
search_maps()
search_youtube()

This would make your agent more capable and versatile, allowing it to answer a wider range of questions with real-time information.

In Closing

We’ve built a small but functional AI agent without an agent framework. The LLM decides when it needs information, our JavaScript application executes the requested tool, SearchApi retrieves the latest search results, and the results are fed back into the model.

The interesting part isn’t the amount of code. It’s the architecture: an LLM becomes considerably more useful when you give it tools it can decide to use.

From here, you can add more tools, support multiple searches, introduce memory, or turn the CLI into a full-fledged web application. The possibilities are endless.

In simple terms:

MCP is like a USB-C port for AI. Instead of building a custom connection for every app or database, MCP gives AI a standard way to connect to external tools.

For example, imagine an AI assistant that needs to:

• Read files from Google Drive
• Check your calendar
• Query a company database
• Use GitHub
• Search a knowledge base

With MCP:

• The AI knows how to talk using the MCP standard.
• The tool (Google Drive, GitHub, a database, etc.) provides an MCP server.
• They can communicate without needing a unique integration every time.

So, essentially, Model Context Protocol (MCP) is an open protocol that standardizes how AI models and applications communicate with external tools, data sources, and services by defining a common client-server interface.

Now, let’s talk about WebMCP.

• What is WebMCP?
• How to Use WebMCP in Chrome
• Registering Tools via navigator.modelContext
• Registering Multiple Tools or Batching (provideContext)
• Unregistering Tools
• In closing
• Further Reading

What is WebMCP?

Think of this analogy where a real person is interacting with a website. The person can see the page, click buttons, fill out forms, and navigate through the site. Now, imagine an AI agent doing the same thing. Normally, an AI agent behaves like a person using a browser. It has to inspect the DOM, find buttons, understand layouts, and hope the UI hasn’t changed.

In a nutshell, the AI agents (such as an in-browser agent, Claude Desktop, or Cursor) attempt to do vision-based browsing where they take screenshots of the page and try to click elements visually.

This approach is slow, expensive (vision tokens cost more), and error-prone when handling complex UIs (e.g., hover menus or sliders). And this is where WebMCP comes in.

With WebMCP, the website explicitly tells the AI agent, “Here are the things you can do and the data you can access.” And so, it doesn’t have to guess or scrape the page to do its thing.

So, a concise definition of WebMCP goes like this.

WebMCP is a browser-based implementation of the Model Context Protocol (MCP) that enables web applications to expose standardized tools, resources, and prompts directly to AI agents running in or through the browser, allowing structured interaction without relying on DOM automation or screen scraping.

WebMCP brings the idea of MCP directly into the browser, allowing web applications to expose MCP capabilities to AI assistants.

In other words:

Web page → WebMCP → AI Agent

instead of

Web page → DOM scraping → AI Agent

So, WebMCP is a bridge between web applications and AI agents, allowing them to communicate in a structured way that is more performant and reliable.

How to Use WebMCP in Chrome

WebMCP is supported starting in Chrome 149 as an origin trial. You can enable support for WebMCP in Chrome by turning on the WebMCP support in DevTools and WebMCP for testing flags in chrome://flags.

Once done, you can see a new WebMCP tab in the Chrome DevTools panel like so.

This tab allows you to inspect and interact with the MCP tools that a web page exposes to AI agents. You can see the registered tools, their input schemas, and even test invoking them directly from the DevTools interface.

Registering Tools via navigator.modelContext

Now, let’s see how a web page can register tools for AI agents to discover and use. This is done using the navigator.modelContext API.

So, for instance, if you want to register a tool that allows an AI agent to add a new to-do item on your web app, you can do it like so.

// Check if WebMCP API is supported in the browser
if ("modelContext" in navigator) {

  // Register an individual MCP tool
  navigator.modelContext.registerTool({
    name: "add_todo",
    description: "Adds a new to-do item to the user's task list.",
    inputSchema: {
      type: "object",
      properties: {
        title: {
          type: "string",
          description: "The description or text of the to-do item."
        }
      },
      required: ["title"]
    },
    // Handler function executed when the AI agent calls this tool
    execute: async ({ title }) => {
      const response = await fetch("/api/todos", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ title })
      });
      const data = await response.json();
      return { success: true, result: data };
    }
  });

}

As you can see, the above code registers a tool named add_todo that takes a title as input and adds a new to-do item to the user’s task list. The execute function defines how the tool behaves when invoked by an AI agent.

You can specify the input schema for the tool using JSON Schema, which allows AI agents to understand what kind of input is expected. In this case, the tool expects an object with a title property of type string and that it’s a required field.

Instead of writing a whole execute function, you can also return a preexisting function or a simple action like showing a toast notification.

execute: ({ title }) => {
    return showToast(title);
}

So, now, when an AI agent discovers this tool, it can invoke it with the required input, and the web page will handle the request accordingly.

Registering Multiple Tools or Batching (provideContext)

You can also pass a collection of context tools like so.

// Example batching multiple tools using navigator.modelContext
navigator.modelContext.provideContext({
  tools: [
    {
      name: "list_todos",
      description: "Retrieves all current to-dos for the user.",
      inputSchema: { type: "object", properties: {} },
      execute: async () => {
        const res = await fetch("/api/todos");
        return await res.json();
      }
    },
    {
      name: "toggle_todo",
      description: "Toggles a to-do item as completed or incomplete.",
      inputSchema: {
        type: "object",
        properties: {
          id: { type: "string", description: "The ID of the to-do item" }
        },
        required: ["id"]
      },
      execute: async ({ id }) => {
        const res = await fetch(`/api/todos/${id}/toggle`, { method: "POST" });
        return await res.json();
      }
    }
  ]
});

All the exposed tools can be viewed in the WebMCP tab in Chrome DevTools, and AI agents can discover and invoke them as needed.

As you can tell, you can tweak the parameters of the tools and run the tool directly from the DevTools interface to see how it behaves. All the activity for these tools will be logged in the Tool Activity section of the WebMCP tab once an AI agent invokes them.

Here’s what it looks like in action.

Unregistering Tools

When a tool should no longer be available to the agent (e.g., when navigating away or changing user state), you can unregister it.

// Unregistering a specific MCP tool by name
navigator.modelContext.unregisterTool("show_toast");

In closing

WebMCP marks an important step toward an AI-native web by enabling web applications to expose their capabilities through a standardized interface instead of relying on UI automation or HTML parsing. This makes AI interactions more reliable, efficient, and resilient to interface changes.

Its potential spans a wide range of applications—from note-taking and project management tools to e-commerce, travel, banking, and content platforms. As AI assistants become a natural part of our daily workflows, WebMCP could become the standard way websites communicate with them, much like REST APIs did for traditional applications.

Further Reading

• WebMCP — AI on Chrome
• Official WebMCP GitHub Repository
• WebMCP is AWESOME! by Mehul Mohan

Yet the thing that caught my attention while using Antigravity wasn’t the AI at all. It was something completely unrelated to the recent AI boom and, in software development terms, almost dinosaur-age old.

• Rediscovering Worktrees
• Agent Branches in Action
• Under the Hood
• In Closing

Rediscovering Worktrees

Git worktrees aren’t new to me. In fact, I made a video about them back in 2021, calling them a better alternative to Git Stash. At the time, I viewed them as a handy Git feature for juggling multiple pieces of work without constantly stashing and unstashing changes. Useful, certainly, but not something I reached for every day.

That perspective started to change when I noticed Antigravity exposing worktrees directly in its interface. Instead of burying them behind terminal commands, it treated them as a first-class workflow. I decided to lean into that workflow while building a few small features, creating separate worktrees for each one.

What followed wasn’t a lesson in how Git worktrees work since I already knew that part. Instead, it was a realization that worktrees solve a much bigger problem than I had originally given them credit for. Antigravity made me see them not as a convenience feature, but as a compelling way to organize and isolate development work in an AI-assisted world.

So, those of you who aren’t familiar with Git worktrees, they allow you to have multiple working directories associated with a single Git repository. Each worktree can be on a different branch, and you can switch between them without affecting the others. This means you can have multiple branches checked out at the same time, each in its own directory.

Agent Branches in Action

Antigravity uses this feature to let you create “agent branches” for each task or feature you’re working on.

Instead of having a single “main” branch where all your work happens, you can have multiple branches that are isolated from each other.

This is especially useful when you’re working on multiple features or tasks simultaneously, as it prevents changes from one branch from affecting the others.

Here’s what it looks like in Antigravity.

As you can tell, Antigravity makes it easy to create a new worktree or continue working from a previous one. Every feature gets its own workspace, making context switching feel much more natural.

The best part about it is that you can easily switch between these worktree branches without worrying about saving or stashing changes right from the Antigravity interface!

Under the Hood

Now, if you run git status in the terminal, here’s what it looks like.

As you can tell, when you run git status, it shows all the branches created under the worktree, and when you try to check out one of these branches, it won’t let you do that because the branch is already checked out in another worktree (which resides under a namespace under the .gemini folder, usually in your computer’s home directory).

Main Workspace
└── main

Worktree #1
└── add-score-tracking-game

Worktree #2
└── simple-3x3-sudoku-game

This means each task gets:

• a dedicated branch
• a dedicated checkout
• a dedicated filesystem

which is exactly what enables concurrent agent execution.

Quick tip: You can list all the worktrees in your repository by running git worktree list. This will show you all the worktrees that are currently checked out, along with their paths and the branches they are on.

If, for some reason, you want to manually make changes in one of these branches, you need to switch to that worktree directory first and then make your changes. And once you’re done, you commit from these branches, or merge them back into the main branch just like you would with any other Git workflow.

In Closing

What I like most about this approach is that it makes context switching almost effortless. Instead of juggling branches, stashing changes, or maintaining multiple clones of the same repository, each feature lives in its own isolated workspace. The result is a workflow that feels cleaner, safer, and easier to reason about, especially when multiple streams of work are happening in parallel.

Git worktrees aren’t new, but Antigravity gave me a fresh perspective on them. Rather than treating them as an obscure Git feature reserved for edge cases, it elevates them into a core part of the development experience. And after spending some time with this workflow, I’m starting to think that worktrees may be one of Git’s most underrated features.

Essentially, most fonts (apart from monospaced fonts) use proportional spacing, which means that each character takes up a different amount of horizontal space. This can lead to numbers looking uneven and misaligned, especially when they’re displayed in a tabular format.

Here’s what it looks like.

This creates issues when numbers change, let’s say in clocks or counters, the text/numbers shifts horizontally, which can be visually jarring. In other words, it will cause a layout shift, which is not a good user experience.

To fix this issue, you can use the font-variant-numeric CSS property (which I recently stumbled upon) with the value tabular-nums.

This will force all the numbers in the font to take up the same amount of horizontal space, creating a more uniform and visually appealing look. Once this property is applied, the numbers behave like monospaced digits, even in proportional fonts.

I’ve created a CodePen demo to show you how it works.

See the Pen Tabular Numbers Demo by Amit Merchant (@amit_merchant) on CodePen.

Now, you might be wondering, what are all the places where this can be useful?

Well, here are a few examples:

• Clocks and timers
• Financial tables
• Analytics dashboards
• Scoreboards
• Any place where numbers are displayed in a tabular format

Also, this property is supported in all modern browsers, so you can safely use it in your projects without worrying about compatibility issues.

Read more about the font-variant-numeric property on MDN Web Docs.

Essentially, the Laravel AI SDK abstracts away the complexities of working with AI models (such as OpenAI, Anthropic, Gemini, Mistral, Ollama, and more) and provides a seamless experience for developers to leverage AI in their applications. It supports various AI services, including natural language processing, image recognition, and more.

You can check this page to learn how to get started with the Laravel AI SDK and explore its features. In this article, though, I want to share some real-world examples of how you can use the Laravel AI SDK in your applications.

• Mining user data for insights
• Code Review Bot for PRs (GitHub / GitLab Integration)
• Personalized Learning / Quiz System for an EdTech App
• In closing

Mining user data for insights

The simplest use case of the Laravel AI SDK is to mine user data for insights. For instance, you can use the SDK to analyze user models and related data to extract valuable insights.

For instance, you can use the User + Order Eloquent models as context for your AI queries.

Here’s an AccountAssistant assistant class that uses the Laravel AI SDK to analyze user data and provide insights:

// app/Ai/Agents/AccountAssistant.php

namespace App\Ai\Agents;

use App\Models\User;
use App\Models\Order;
use Laravel\Ai\Contracts\Agent;
use Laravel\Ai\Contracts\Conversational;
use Laravel\Ai\Promptable;
use Stringable;

class AccountAssistant implements Agent, Conversational
{
    use Promptable;

    public function __construct(public User $user) {}

    public function instructions(): Stringable|string
    {
        return 'You are an assistant helping a customer with their account and recent orders.';
    }

    public function messages(): iterable
    {
        // You might combine past chat messages from a History model,
        // but you can also “prime” the conversation with DB data:
        $orders = Order::where('user_id', $this->user->id)
            ->latest()
            ->limit(5)
            ->get()
            ->map(fn ($order) => "- #{$order->id} ({$order->status}) total {$order->total}");

        return [
            // System / context message built from Eloquent:
            new \Laravel\Ai\Messages\Message(
                'system',
                "Here are the user's 5 most recent orders:\n".$orders->implode("\n")
            ),
        ];
    }
}

And then use it like this:

$assistant = \App\Ai\Agents\AccountAssistant::make(user: $user);

$response = $assistant->prompt('Where is my last order?');

return (string) $response;

In this example, the AccountAssistant class implements the Agent and Conversational interfaces provided by the Laravel AI SDK. The instructions method provides context for the AI model, while the messages method retrieves the user’s recent orders from the database and formats them as a system message.

When you call the prompt method with a user query (e.g., “Where is my last order?”), the AI model will analyze the provided context and generate a response based on the user’s recent orders.

Code Review Bot for PRs (GitHub / GitLab Integration)

You can use the SDK to build an internal “AI reviewer” that comments on pull requests in your Laravel monorepo.

At a high level:

• When a PR is opened or updated, your CI pipeline (or a small Laravel service) fetches the diff and key files.

• You create an agent like CodeReviewer whose instructions() explain your team’s standards: coding style, architecture rules, security expectations, performance guidelines, etc.

• In prompt(), you pass a structured prompt: a short summary of the PR, the diff, and maybe a list of changed files as attachments (e.g. Files\Document::fromString($diff, 'text/plain')).

• The agent uses structured output to return something like:

  • summary: overall explanation of changes

  • issues: list of problems with severity and file/line hints

  • suggestions: refactors or tests to add

• Your Laravel app then maps that output to actual comments on the PR via the Git hosting API.

This leverages agents, attachments, and structured output, but in a domain (code review automation) not explicitly shown in the docs.

Personalized Learning / Quiz System for an EdTech App

Imagine you’re building an online course platform and want smarter, adaptive practice for students.

You could use the AI SDK to:

• Generate personalized quizzes from course content

When a student finishes a lesson, call an agent like QuizGenerator with:

• Instructions: “You are an exam coach. Generate questions only from the given lesson content, aligned to this student’s weaknesses.”

• Messages: include a summary of what the student just studied, plus their past quiz results.

• Attachments: lesson notes or slides as Files\Document::fromStorage(...).The agent uses structured output to return a schema like:You then persist these questions in your quizzes and quiz_questions tables.

• Adapt difficulty using conversation context

Implement Conversational or RemembersConversations so the agent can see previous attempts, topics the student struggled with, and feedback given. The next quiz can intentionally focus on weak areas or gradually increase difficulty.

• Explain answers on demand

A second agent, AnswerExplainer, takes the student’s wrong answer and the original question as prompt, and returns a tailored explanation (“why B is wrong and C is right”), again via structured output so you can show explanations, hints, and follow‑up questions cleanly in your UI.

• Enhance with embeddings and reranking

• Use Embeddings + whereVectorSimilarTo to find the most relevant paragraphs in your course material for each question.

• Use Reranking to reorder candidate questions so the most relevant and appropriate ones are presented first.

This gives you an adaptive learning system built entirely on top of the Laravel AI SDK primitives: agents, structured output, files/attachments, conversation memory, embeddings, and reranking.

In closing

These are just a few examples of how you can use the Laravel AI SDK in real-world applications. The SDK provides a lot of flexibility and power (such as remembering conversations and middleware), allowing you to build intelligent features that can enhance user experience and provide valuable insights.

Whether you’re mining user data, automating code reviews, or creating personalized learning experiences, the Laravel AI SDK has you covered.

It’s a really well-written piece that I highly recommend you to read. But I was wondering what they are using under the hood to add these sounds since the article itself doesn’t mention any libraries or tools. So, like always, I dug the source code, and I found there’s this magic library called SND (also open-source) is being used to add these sounds.

Now, it’s pretty interesting because SND is a tiny JavaScript library that makes it super easy to add UI sounds to your web applications. It provides a simple API to play sounds for various UI interactions like button clicks, notifications, warnings, errors, and more.

And as the article title suggests, it literally takes just a “heartbeat” to add sounds to your web apps with SND.

SND takes an interesting approach to use the sounds where once the library is included in your app, you just need to add predefined classes to the HTML elements where you want the sounds to be played.

SND lets you choose from three audio kits, all of which have different sound signatures: sine, piano, and industrial

So, for instance, you can include the SND library with the sine kit like this:

<script src="https://cdn.jsdelivr.net/gh/snd-lib/snd-lib@v1.2.4/dist/browser/snd.js?kit=01"></script>

Here, the kit=01 query parameter indicates that we want to use the sine kit. Similarly, you can use kit=02 for the piano kit and kit=03 for the industrial kit.

Next, if you want to play a click sound when a button is clicked, you just need to add the class snd__button to the button element like this:

<button class="snd__button">Click Me</button>

And the button starts playing a click sound on every click, just like that. No additional JavaScript code is needed!

Here’s a CodePen demo that I created to showcase how SND works.

See the Pen SND lib demo for UI sounds by Amit Merchant (@amit_merchant) on CodePen.

The good thing here is that even on repeated clicks, the sound plays without any delay or interruption. All the nitty-gritty of handling audio playback is taken care of by the library itself.

Also, if you want finer-grained control over the sounds, you can use the JavaScript API provided by SND. For example, you can play a sound programmatically like this:

const snd = new Snd();

snd.load(Snd.KITS.SND01).then(() => {
  // you can add listeners to UI events:
  document.getElementById("btn").addEventListener("click", () => {
    // snd.play(Snd.SOUNDS.CELEBRATION);
    snd.playNotification();
  });
});

One more thing I noticed about SND is that it uses something called audio sprites (like image stripes) to optimize the loading and playback of sounds. Instead of loading individual sound files for each UI interaction, SND combines multiple sounds into a single audio file (sprite) and plays specific segments of that file as needed. This approach reduces the number of HTTP requests and improves performance.

Overall, I’m quite impressed with SND and would definitely consider using it in my future web projects that require UI sounds.

Here’s what it looks like.

As you can see, the text features a beautiful water ripple effect. I dug through the source code and found out that it’s done using the SVG filters!

So, I learned a bit about SVG filters, and here’s what I found out.

SVG filters are a powerful way to apply graphical effects to SVG elements. They can also be applied to HTML elements using the filter CSS property. Without SVG filters, achieving complex visual effects like the water ripple effect would require using images or complex JavaScript animations.

To recreate the water ripple effect, first, define the element you want to apply the effect to. In this case, it’s a simple paragraph with the text “Breathe”.

<p class="ripple-text">
    Breathe
</p>

Next, define the SVG filter that you want to apply.

<svg style="position: absolute; width: 0px; height: 0px; pointer-events: none;">
    <filter id="water-ripple">
        <feTurbulence type="fractalNoise" baseFrequency="0.05" numOctaves="2" result="ripple">
            <animate attributeName="baseFrequency" dur="10s" values="0.02;0.05;0.02" repeatCount="indefinite"></animate>
        </feTurbulence>
        <feDisplacementMap in="SourceGraphic" in2="ripple" scale="5"></feDisplacementMap>
    </filter>
</svg>

As you can tell, we can define a filter using the <filter> element with id water-ripple.

Inside the filter, we use two filter primitives:

• The <feTurbulence> element - It’s used to create a noise texture, which is then animated to simulate the water ripple effect.
• The <feDisplacementMap> element - It’s used to apply the turbulence effect to the text.

There are a bunch of parameters on these filters that you can tweak to achieve different effects.

For instance, in the <feTurbulence> element, we set the type to fractalNoise, which creates a fractal noise pattern. The baseFrequency controls the frequency of the noise, and numOctaves controls the complexity of the noise.

Similarly, for the <feDisplacementMap> element, the in attribute specifies the input image (in this case, the original text), and the in2 attribute specifies the turbulence effect created by <feTurbulence>. The scale attribute controls the amount of displacement applied to the text.

Also, the SVG is hidden from viewing by setting its width and height to 0 and positioning it absolutely.

Fun fact: The fe in the filter primitive names stands for “filter effect”.

Finally, apply the filter to the text by using the id of the filter in the CSS.

.ripple-text {
    filter: url(#water-ripple);
    font-size: 3rem;
    font-weight: bold;
}

And that’s it! You now have a beautiful water ripple effect applied to your text using SVG filters.

I found this cool SVG filter playground where you can experiment with different filter primitives and see the effects in real-time. You can stack multiple filter primitives, change their parameters, and create complex effects.

And if you want to learn more about SVG filters, check out the MDN documentation on SVG filters for a comprehensive guide on how to use them.

In scenarios like these, having a built-in function to clamp values can be incredibly useful. Well, good news! PHP 8.6 will be introducing a new function called clamp() that does exactly that.

• What is the clamp() function?
• Clamp with named parameters
• Real-world use cases
• Conclusion

What is the clamp() function?

PHP 8.6’s clamp() function allows you to restrict a value to be within a specified minimum and maximum range. If the value is less than the minimum, it returns the minimum; if it’s greater than the maximum, it returns the maximum; otherwise, it returns the value itself.

Here’s the signature of the function:

clamp ( mixed $value, mixed $min, mixed $max ) : mixed

As you can tell, clamp takes three arguments, a $value, $min, and $max, then checks if $value is within the bounds of $min and $max (both inclusive).

• If $value is less than $min, it returns $min.
• If $value is greater than $max, it returns $max.
• If $value is between $min and $max, it returns $value.

It throws a ValueError if min > max or if min/max are NAN.

Here’s a simple example of how it works:

$value1 = clamp(15, 10, 20); // Returns 15
$value2 = clamp(5, 10, 20);  // Returns 10
$value3 = clamp(25, 10, 20); // Returns 20

Fun fact: A long time ago, I wrote a custom clamp function in PHP as a utility function for my projects.

Clamp with named parameters

The clamp function becomes even more straight-forward with named parameters and re-ordering of the arguments.

$brightness = clamp(min: 0, value: $brightness, max: 100);

Real-world use cases

Here are some practical scenarios where the clamp() function can come in handy.

User input: keep a percentage between 0 and 100

$percentage = clamp($percentage, 0, 100);

UI sliders: constrain a volume setting between 0 and 10

$volume = clamp($volume, 0, 10);

Pagination: bound page number between the first and last page

$page = clamp((int)$_GET['page'] ?? 1, 1, $totalPages);

Rate limiting: prevent burst count from exceeding a ceiling

$requests = clamp($requests, 0, $maxBurst);

Dates: ensure a booking date falls within an allowed window

$date = new DateTimeImmutable($input);
$start = new DateTimeImmutable('2025-08-15');
$end   = new DateTimeImmutable('2025-09-15');
$clamped = clamp($date, $start, $end); // returns start/end/date accordingly

Geometry: restrict an angle between 0 and 90

$angle = clamp($angle, 0, 90);

Strings (lexicographic): keep a tag between “c” and “g”

$tag = clamp($tag, "c", "g");

Conclusion

The clamp() function in PHP 8.6 is a simple yet powerful addition that can help you manage values effectively by enforcing boundaries. Whether you’re dealing with user input, configuration settings, or any scenario where you need to ensure values stay within a specific range, clamp() provides a clean and efficient solution.

Read more about the clamp() function in this RFC.