ARGUS

Every creative team ends up with the same problem, just at a different scale: a library of thousands of photos and graphics, sitting in folders named by date or by whoever exported them last, and no way to find "the warm, celebratory hero shot" inside that pile without opening every file by hand. Manual tagging is the fix everyone reaches for, and it's also the fix that never finishes — it's backlog work, and backlog work always loses to whatever shipped yesterday. What I wanted was something that reads an image the moment it lands and writes down what's actually in it — palette, mood, composition, visual language — so the search that follows is about meaning, not filenames.

I built Argus alone, nights and weekends, around everything else — no team, no outside budget, nothing resembling a deadline. It started as an itch, not a roadmap item, and I think that shows in the decisions below: there was no one else in the room to weigh in, so each one got made once, and had to be right enough to live with.

There's one decision here worth explaining, because from the outside it looks like foresight, and it really wasn't.

Two API surfaces from day one — REST and MCP — instead of just one.

Argus exposes the same asset graph two ways: a REST API for anything that isn't an agent, and an MCP server at argus.build/mcp for Claude and other agents to call directly. I didn't build both because I'd mapped out some future where agents mattered more than scripts — I built both because I had two different use cases in mind at the same time, and testing them in parallel turned out to cost almost nothing, since they share the same test suite underneath. I still don't know which use case wins. Building both just meant I didn't have to decide yet.

Here's how it actually works, mechanically. Upload triggers analysis asynchronously — the API hands back a response in under 3 seconds and the actual vision pass runs in the background, so the write path never blocks on a model call. Analysis results (palette, mood, tags) land in a searchable index; semantic queries like "warm, celebratory hero shot" run against that index and come back ranked by relevance rather than exact match. Authentication runs through two token types: long-lived ak_-prefixed API keys for normal integrations, and short-lived at_-prefixed agent session tokens that can't mint new keys or escalate privileges — a narrower blast radius for anything an agent is holding mid-transcript.

The MCP server.

This is the piece other engineers will actually want detail on. It's a hosted endpoint at argus.build/mcp, not a local process — an agent connects to it the way it'd connect to any other MCP server, no separate SDK required. It exposes over 20 tools — search_assets, get_asset, upload_from_url, generate_style_guide, and adapt_svg_to_palette among them — the same operations available over REST, just wrapped for tool-calling instead of HTTP verbs. That parity is the whole point of building both surfaces: an agent working through MCP and a script hitting REST are working against the identical asset graph, not two versions of the truth.

If I'm honest, there's nothing I'd change. Argus was never about shipping fast — it was about sitting with every piece of the problem long enough to actually understand it: what creative teams need from a tool like this, and just as importantly, what kills the experience when an agent gets it wrong.