Coding agents are remarkably capable right up until they need information that isn’t already sitting inside their context window. Then things get interesting.

I use coding agents heavily, particularly Pi, and one recurring annoyance was giving the agent access to the web without dragging an entire browser-shaped dependency tree into the workflow.

Sometimes the agent just needs to search for something. Sometimes it needs to actually look at a webpage. And sometimes the webpage has decided that putting useful information in the DOM is unfashionable, let’s put them in pictures.

So I built agent-context-feed (GitHub).

An agent working on a codebase has a fairly simple problem: its world ended on the day its training ended.

If the answer isn’t in the training data, repository, prompt, documentation already loaded, or one of its tools, the agent has to guess. There is a word for it; starts with the letter ‘H’.

What I wanted was much simpler:

Give the agent a cheap way to fetch external context when it actually needs it.

Not a giant browsing framework. Not seventeen MCP tools describing every conceivable interaction with a webpage.
Just: search → retrieve → feed useful context back to the agent

This is where agent-context-feed comes in. It is a small Python CLI that gives AI agents two ways to retrieve information from the web. The default mode searches the web using DuckDuckGo through the ddgs library and returns structured results. It doesn’t launch a browser at all.
When search results aren’t enough, URL mode launches Chromium through Playwright, opens the requested page, captures a full-page screenshot and extracts its visible text. And because the web occasionally consists of pixels pretending to be a document, there’s an optional Tesseract OCR mode for extracting text from the screenshot instead of relying on the DOM.

Conceptually, it looks like this:

Agent
  │
  ├── needs information
  │
  ▼
agent-context-feed
  │
  ├── search
  │     └── DuckDuckGo
  │
  └── webpage
        ├── Playwright
        ├── screenshot
        ├── DOM text
        └── OCR (optional)
  │
  ▼
structured context
  │
  ▼
Agent continues working

Nothing revolutionary. Which is precisely the point.

The normal path is intentionally boring:

google-search "angular signal store testing"

That uses DuckDuckGo and returns structured search results as JSON. No browser is required.

You can also constrain the amount of context returned:

google-search --max-results 5 --pretty "nx affected"

This matters more than it initially sounds. With agents, retrieving information isn’t free just because the search API is free. Whatever you retrieve eventually becomes tokens. Returning ten pages of garbage so the model can discover that result number three contained the answer is not retrieval. It’s catering.

Sometimes the agent actually needs the page. Search snippets only get you so far. For that, there’s URL mode:
The tool launches Chromium using Playwright, loads the page, takes a full-page screenshot and extracts the visible DOM text. The result comes back as JSON. So the agent gets machine-readable text while I still get the screenshot when visual inspection matters.

And then there are websites that hate the DOM

Naturally, some sites render important information into canvas elements or images. Because displaying text as text would apparently have been too easy.
For those, we have OCR built right in. The tools is built to run Tesseract over the captured screenshot rather than extracting the page’s DOM text. Tesseract is deliberately optional because normal URL mode doesn’t need it. Tesseract specifically because it os lightweight and can give you results in seconds running on your CPU.

The Pi integration

I primarily wanted this for Pi, so the repository also includes a ready-made Pi extension. The extension registers a google-search tool inside Pi and shells out to the CLI. It exposes both DuckDuckGo and URL modes, including DOM/OCR extraction.
The tool is wrapped as an extension and models can use them as needed.

Why this?

Because I’m increasingly interested in agent efficiency, not merely agent capability. There is a tendency with coding agents to keep adding tools:
read_file
write_file
search_files
browser
browser_click
browser_scroll
browser_screenshot
browser_extract
browser_back
browser_forward
search_web
fetch_url
…

Every tool needs a description. Every description occupies context. Every additional capability gives the model another decision to make. Eventually you’ve built an extraordinarily sophisticated system for asking an LLM whether it would like to click a button.

For this use case I wanted one narrow interface that answers a simpler question:

What external information does the agent need right now?

Search if search is enough. Fetch the page if it isn’t. OCR the pixels if the web developers have committed crimes. Then give the result back to the model. You don’t have to worry about DOM changes, dynamic content, HTML Tags.

What this isn’t

This isn’t trying to become a full browser-use agent. There is no autonomous clicking around websites, filling forms, buying GPUs at 3 AM or negotiating with cookie banners. It retrieves context. That’s it.
The current project is intentionally small: a Python CLI, DuckDuckGo search, Playwright webpage capture, optional Tesseract OCR, JSON output, and a Pi extension wrapping the whole thing. The interest lies in only optimizing and making things easy and that’s what this does.