How to Build a Pi-Like AI Agent with Web Search

In 2023, Inflection AI launched a chatbot called Pi that, instead of simply executing commands, held a conversation like an actual companion and remembered details across sessions. Since then the company has shifted its focus toward enterprise customers, but the underlying idea stuck. People want more than a task executor. They want an agent with a personality that remembers context and can check current information online instead of relying only on what the model learned during training.

This guide walks through building an agent like that yourself, on your own server. You will need a language model with function calling support, a simple memory store, and a web search tool. The instructions are aimed at developers who want a personal assistant without someone else’s usage caps or a dependency on a product that could change its rules at any point.

This is not about cloning a specific product. It is about the pattern behind it: a personality defined up front, memory that survives between sessions, and the ability to verify facts online instead of relying purely on training data. You can put together an agent like this on a modest server in an evening, once you understand the moving parts and which tools make sense for your setup.

What Makes a Pi-Style Agent Different From a Regular Chatbot

A regular chatbot answers a question and forgets the conversation the moment you close the tab. A Pi-style agent works differently. It has a personality defined ahead of time (tone, style, how it phrases things), and memory that outlives the session. When you come back, it remembers what you talked about before.

The second difference is how it handles facts. A standard model answers based on whatever it learned during training, and that training data has a cutoff date. An agent with web search can pause and check a current source before answering, whenever the question touches on something that could have changed.

It is worth distinguishing this kind of agent from task agents like OpenClaw, which read email, update a CRM, and run commands in a terminal. Those prioritize getting things done. Here the priority is conversation, memory of the user, and factual accuracy rather than automating routine work.

Inflection itself is a useful cautionary example. After key team members left for Microsoft, the company shifted Pi toward enterprise customers, and that is not an isolated pattern. Consumer AI products tend to drift toward business customers eventually, because that is where the revenue is steadier. Anthropic made a similar move recently, changing how its Claude subscription handles third-party agent frameworks so that heavy agentic usage is billed separately from the flat monthly plan. If you want a companion that answers to you and not to a pricing committee, running it yourself is the more durable option.

The Three Parts Every Agent Like This Needs

Under the hood there are three components.

The language model. It handles reasoning and generates the response. Your choice of model determines the quality of the conversation, response speed, and how natural the agent sounds.

Memory. This splits into short-term (the last few messages in the current conversation) and long-term (facts about the user that persist between sessions: name, preferences, project details). Without that split, the agent either forgets everything after a restart or drags the entire conversation history into every request, which gets slow and expensive fast.

A web search tool. A separate function the model can call whenever it needs current information. Technically this is tool calling: the model writes a search query, gets results back, and continues the answer with that information in hand.

These three parts are independent of each other. You can swap the model without touching memory, or replace the search provider without rewriting the conversation logic. That separation matters in practice. If one provider raises prices or restricts access, you change one block instead of rebuilding the whole agent.

Next, let’s look at how to pick a model and a search provider for these three components.

Choosing a Model: OpenAI, Anthropic, or a Self-Hosted Open Model

For most developers in the US, this step is refreshingly simple. Both the OpenAI API and the Anthropic API are directly accessible with a credit card and an API key, no workarounds required. Both support function calling, which is what lets the model call your search tool.

OpenAI’s API gives you access to the GPT family of models through a well-documented SDK with mature tooling around it. Billing is usage-based, so costs scale with how much the agent is actually used rather than a flat subscription fee.

Anthropic’s API gives you access to the Claude family, also with function calling and usage-based billing. Worth noting: Anthropic’s own consumer Claude subscription no longer covers heavy usage through third-party agent frameworks, so if you are building this on top of a personal Claude subscription rather than the API directly, check the current terms before you assume unlimited usage.

A self-hosted open model through Ollama (Llama, Mistral, or similar) is the third option, and it makes sense if privacy or long-term cost control matters more than raw quality. You trade some capability for zero per-message API cost and full control over where the data lives. This requires more RAM on your server than the API-based options, since the model itself runs locally rather than in the cloud.

For a first version, an API-based setup (OpenAI or Anthropic) gets you running fastest, since there is no proxy or translation layer to configure between your code and the model. If cost or data residency becomes a concern later, that is when a local model through Ollama is worth the extra setup effort.

Choosing a Web Search Tool for the Agent

A model without search answers from memory, and that memory has a cutoff date. If the agent needs to handle exchange rates, current news, or up-to-date prices, it needs a separate tool that reaches out to the internet mid-conversation.

Here are the main options that plug into an agent as a tool, along with their limits and pricing.

Response time matters here almost as much as price. A search call that takes several seconds adds noticeable lag to the conversation, so it is worth testing latency with your actual query patterns before committing to a provider.

What to Prepare Before You Start

Before diving into setup, get the following ready:

• a Linux server; for a chat agent with search, 2 vCPUs and 2 to 4 GB of RAM is enough, you don’t need the heavier specs a browser-automation agent would require
• Docker or Node.js installed
• an API key from OpenAI, Anthropic, or your chosen provider
• an API key for the search service you picked
• a Telegram bot token from @BotFather

Any standard VPS works for this. Renting a VPS with Ubuntu preinstalled covers every item on that list, and getting from a fresh server to a working test message takes about an hour.

Step-by-Step: Building the Agent

Here is the process broken down step by step, from the server to the first message in Telegram.

Set Up the Server and Environment

Provision a VPS and connect over SSH. Then update the system and install dependencies:

If you haven’t picked a host yet, a VPS with Ubuntu preconfigured saves time here since the base system is already ready and you just install the packages above.

Connect the Model

With OpenAI or Anthropic, there’s no proxy bridge to configure since both APIs speak a standard, well-documented format out of the box. A basic test call looks like this:

If you get a response back, the connection works and the agent is ready to call the model from your own code.

Give the Agent Web Search Access

Web search plugs in as a function: you describe to the model what tool is available, what parameters it takes, and when it should be used. Here’s an example tool definition in JSON:

When the model decides it’s missing information, it calls this function with a query it wrote itself. Your code sends that query to the search API you picked, gets results back, and returns them to the model, which then writes the final answer using that information.

Build Memory: Short-Term and Long-Term

Short-term memory is easiest to implement as a buffer of the most recent messages in the current conversation, passed to the model along with each new question.

Long-term memory is worth keeping separate. A simple approach is a SQLite table with columns like “user,” “fact,” and “date.” After each conversation, a separate model call can extract facts worth remembering (name, preferences, details about ongoing projects) and save them to that table. On the next conversation, those facts get pulled back in and added to the system prompt before the actual dialogue starts.

The split matters because without it, the agent either loses context between sessions or drags the entire accumulated history into every single request, which increases cost and slows down responses.

Give the Agent a Personality

The agent’s personality lives in a system prompt, a separate text file loaded at startup. This is where you define the name, tone, and boundaries of what the agent can and can’t do. For example:

You are a personal assistant named Piper.
You speak warmly but get to the point, no filler.
You remember details from past conversations and use them
when relevant. If you're missing current information, you
always check via search rather than guessing.

Keeping this in a separate file makes it easy to tune the tone without touching the rest of the code.

Deploy to Telegram and Launch

The simplest interface for an agent like this is a Telegram bot. In Python, the python-telegram-bot library handles this: the bot receives a user’s message, passes it to your handler function (model plus memory plus search), and sends the result back.

To keep the agent running through server reboots, set it up as a systemd service or run it in Docker with the restart-always flag. Send a simple first message to confirm all three pieces, model, memory, and search, are actually working together.

Strengths and Weaknesses of This Setup

On the plus side: full control over your data and logic, no third-party message caps, computation happens on your own server rather than inside a closed product, and costs are predictable since they scale directly with API usage.

On the downside: maintenance is entirely on you, including updates and monitoring. If you go the self-hosted open model route to save on API costs, response quality on complex reasoning will lag behind the top commercial models. And you’ll need to keep an eye on your search API usage, especially on a free tier, so the agent doesn’t go quiet mid-month.

One more thing worth planning for upfront: an agent that keeps long-term memory about a user is, by definition, storing a record of personal conversations. If this moves beyond a personal hobby project and other people start using it, think through where that memory data lives and who can access it, particularly if any of those users are covered by privacy regulations like the CCPA.

Where This Kind of Agent Fits: Use Cases

A personal assistant that remembers your preferences. The agent knows which topics you care about and pulls in fresh material on them through search when you start a new conversation.

A companion for learning a language or a subject. It remembers your progress between sessions and can verify a current example or piece of news related to what you’re studying, right in the conversation.

A tracker for personal projects. It holds context on ongoing work and can check current data, whether that’s an exchange rate, hardware pricing, or the release status of a library you depend on.

A morning or evening briefing. An agent that gives you a short daily rundown of what matters, drawing on fresh search results and what you discussed the day before.

A prototype for something more ambitious. If you’re planning an agent with a wider set of tools down the line, this combination of model plus memory plus search is a reasonable starting point before adding complexity.

Common Mistakes When Setting This Up

Mixing short-term and long-term memory into a single context without any structure. The result is either an agent that forgets important details or a request payload that gets needlessly long and expensive with every message.

Leaving the “should I search or not” decision entirely to the model with no explicit rules. The model either skips search when it actually needs current data, or calls it on every minor question and burns through your API quota.

Hardcoding API keys directly in your code, or worse, committing them to a public repository. Use environment variables, and double-check your .gitignore before your first commit.

Skipping spending limits on your OpenAI or Anthropic dashboard. Without a cap, a bug that triggers a loop of unnecessary API calls can turn into a surprising bill before anyone notices.

Underestimating free-tier limits on search APIs during testing, only to have the agent go quiet on current-events questions partway through the first real month of use.

Forgetting to age out long-term memory. If it accumulates facts without any review, it fills up with outdated or contradictory entries over a few months, and the agent starts confusing a user’s current preferences with old ones.

What to Do Next

An agent with a personality, memory, and web search comes together from three understandable parts: a model with function calling, memory split into two layers, and a search tool. For a first version, OpenAI or Anthropic’s API paired with one of the search providers above gets you running fast, and the infrastructure underneath it, including a VPS with Docker, is something you set up once and then just maintain.

From here, most people extend an agent like this by adding more tools (a calendar, notes, a personal knowledge base) and smarter long-term memory with semantic search over accumulated facts. But even in the basic setup described above, the agent is already capable of holding a conversation that remembers context and doesn’t rely on stale information.