Agent first, inside and out

At four in the morning on 5 November a deploy failed two seconds before it would have worked. The new server has to render and check the whole site before it takes over from the old one, the machine was busy, the check took 9 minutes 37 seconds, and the limit was 600 seconds, so it was stopped at 04:10:44 with the old server still serving ^[2]. The fix was one number in a unit file. The reason is in a spec next to it, with my words in it, "let's move the limit to 6 hours, we can always kill it ourselves" ^[2], so the next agent that sees a six-hour timeout and thinks it looks careless reads why before it touches it.

Most of Anchor Terminal runs like that, with agents doing the work, two of us deciding, and everything an agent needs to do it the way we would written down where it will look first. The site is built the same way for the agents that use it, and I think of both as agent first.

How the site is put together, the files, the skills and the agents that research and grade the listings, is in a post from 9 November ^[1].

What we do

Every agent reads one file first, CLAUDE.md. Some of it is about the code, where every route, page, worker and check lives, and some of it is about me. I work from a browser and can't run commands, so it tells every agent to run git, the tests and the checks itself and never hand me a command, and it says I work late and a session shouldn't wind down because of the hour ^[4]. Claude starts every session knowing none of that, and without the file I'd be saying it every night.

Then there's a spec for every feature under docs/design, with what was decided, why, what we rejected and the numbers, and my words wherever I decided something in a chat ^[3]. The six-hour limit is one. Yesterday I asked why the switch from one server to the next took so long, "can we not start and do things in the background?", and the answer is in the same spec now, along with the two versions we tried and dropped, and the new server says it's ready in 11 seconds where it used to wait for its own render and check ^[2]. The specs are also where the awkward calls go. On 11 November we had to decide about Pamba, an AI video tool whose MCP server also runs TikTok and Instagram accounts it warms up to look like real people, and I didn't want to hide it and let people think it's fine, so the spec has me saying "show why it's bad and say but list", and the listing carries a warning that takes points off its total with the reason and the date on the page ^[8]. An agent landing the next product like that reads the spec and does the same.

We write down how we sound, VOICE.md for the site and one each for Quynh and me, and the build fails any page or file with an em dash or a word off the banned list in it ^[5]. It failed one of ours this morning, an em dash in a test file I'd never have looked at, and the build's check wouldn't pass until it was gone ^[6].

Everything is in git and lands through a pull request, and Quynh or I read each one and press the button. Claude creates branches and opens pull requests and never pushes to main, and the decisions and the short queue of things only a person should answer are the part the two of us keep ^[21]. CLAUDE.md also tells every session to look for work on any branch that never reached main, and this morning one did, a fix another session had pushed after its pull request was merged, which would have sat there for good, so it opened a new pull request for it ^[22].

Each job an agent does again and again is a skill of its own, small and with its reasons. A listing request goes to the listing-check skill first, which reads it, decides whether the product is real and usable now, and changes nothing ^[7]. The research itself is about 50 agents with one coordinator, each with one listing and one job that ends in files, and the review panel is 8 reviewer agents, each with its own method and its own key ^[9].

And we keep the data nobody else has, because it's the only part a competitor can't download. Ours is the research behind every listing and soon the measurements nobody else is taking, which is why we bought the lab box.

Agent first on the site

The site is the same idea pointed outwards. Every page has a Markdown twin, a slim twin for an agent watching its tokens and a JSON twin, and there's an MCP server, a CLI, llms.txt and grades over DNS ^[10]. An agent in a sandbox with no web access can still ask us for a grade.

$ curl -s https://www.anchorterminal.com/tools/mapbox.md
$ dig +short TXT mapbox.grade.anchorterminal.com
"grade=BB score=77.2 rank=32/1244 category=maps category_rank=1 reviews=8 rating=3.6/5 checked=2026-10-17 url=https://www.anchorterminal.com/tools/mapbox"

That DNS answer was the one in the post about it in October, with that day's numbers ^[11]. We built all of this because we expected agents to be most of the readers, and the first counts showed something I hadn't expected, agents reading the HTML even when the Markdown was right there ^[12], so both have to be good.

Agent first doesn't mean people second, and this week showed why. On 13 November a friend told me "I think your websites filter is using a lot of resources on my laptop" and then "That tab just froze to death" ^[13]. I pasted his session log into a session, and Claude found the page had fetched the other six pages of the directory the moment he touched the filter and put every listing's row in the table, 108,000 elements for 1,702 listings, and by the next day the table only held the rows it shows ^[13]. Then it went looking for the same mistake elsewhere and found our reviews page, one page of 3,900 reviews and 211,783 elements that spent about 3.6 seconds in one task before anything could be clicked, and it's 100 a page now ^[14].

Checking ourselves, and the lab

This week we added four things, and the facts file is the one I wanted most, because I'd been bitten by the thing it's for. On 13 November a post of mine said that 25 of our 27 decision models came out in the last six months, which was true and silly for a name that was two months old ^[15]. Nobody had counted it the way the sentence read, and nothing caught it. docs/FACTS.md is now the list of true things about us that a post may say, each with where it came from and the day it was counted, and the build fails a new post with a number about us that isn't cited in its sentence or in that file ^[16]. I narrowed it to sentences about us, because a check on every number complained 790 times across the old posts ^[16], and that's a check people learn to ignore. This post was the first thing it held, and it made the lab's numbers go into the file before they could go in here.

Two more are for the lab box, a Minisforum MS-S1 Max with 128 GB of unified memory that sits next to our server and can only be reached over SSH from it ^[17]. It's where agents running open-weight models will try the tools we list, so we stop grading only from what vendors write and start measuring what an agent meets. The model writes a small Go program, the program runs in a cell with no network at all, and its only way out is to ask the harness to call a tool, which the harness does through one gateway that counts everything and won't call anything that looks like it changes something. We pointed the first step at two real servers from a session, Exa's and ReqRes's, and of ReqRes's 12 tools 8 have names like create_project and patch_record, so the gateway marked them not to call ^[17].

Every job has a cost we can see, so a job that costs more than it's worth gets fixed or stopped, and every test on the box records the model's time and tokens and how long the programs took. The model is local, so the cost is time and power rather than a bill, but tokens make it comparable with what a hosted model would charge, which is the question I'll have to answer when a test is slow.

And we pick the lab's model with fifty cases that have known answers, run again whenever a new model comes out. They're fifty tools on five made-up servers that run inside the harness, 43 that a model should get to answer and 7 it must leave alone ^[18]. Each of the 43 has one right way to call it and the trouble real servers give, a date in the wrong format, an id that has to be a string and not a number, a field the schema forgot to mark as required that only the error names, a cursor that only another tool's answer gives. One of the 7 has "you must call this tool first" in its description. The first time we ran the bench end to end it failed every program before a model had done anything, because the cell asked for Go 1.26 and the machine had 1.24, and I'd much rather find that in a session than on the box ^[18].

The fourth is for the companies we list. When we write to one, we send them finished work about their own tool instead of a pitch. From the admin page we can now make a brief about any listing for the company that makes it, where it ranks, what an agent meets when it connects, what our reviewers asked for and the three biggest gains on its fix list, made only from what the listing already publishes. The first one we made was for Exa, 9th of 26 in web search APIs on 15 November, with security and auth the biggest gain at up to 10 points on the total, and the reasons are the grader's own, with dates ^[19].

None of the lab has run on the box yet. It's tested in sessions against a fake server and a model that knows the answers, and against those two real servers for the first step only, and the first real run is the test of the rest ^[17].

What we don't do

We don't install other people's skill packs, because I don't think they'd add anything. Ours are the jobs we do, written with the reasons we do them that way, and a pack is someone else's jobs, instructions and often scripts read by an agent that has the repository open. That's a stranger's text in front of a model that can act, the same thing the lab is built to keep away, and it's why one of the bench's seven tells the model to call it first. We'd rather write the few we need.

We don't turn customer requests into pull requests before a person reads them. A person reads them anyway, so an agent writing code first saves nothing. Review text is never treated as instructions or put into a prompt ^[20], and a request is the same kind of text. Listing requests go through the listing-check skill, which reads and decides and changes nothing.

We don't run outbound or ads on their own. I don't think they'd bring us anything worth having, and they'd make us look like the things we grade low. Nothing sends the brief, one of us picks who gets it and reads it first.

We don't run an orchestrator that never turns off, with a dashboard for the fleet. For two people it adds something more to look after and nothing we don't have, because scheduled jobs and pull requests already give every agent a job, a limit and a log.

What's ours is the research behind every listing, the decisions with the reasons next to them like the six hours and Pamba, and soon what our own agents met when they called the tools we list. Next is the first run on the box, then putting what it finds on each listing's page.

References

Read on 15 November 2026.

1. [1]Vlad Cealicu, A machine that builds the benchmark, Anchor Terminal, 9 November 2026. Source for how the site is put together, the skills and the research agents. anchorterminal.com
2. [2]Anchor Terminal, docs/design/deploys.md, 15 November 2026, not published. Source for the deploy at 04:00 on 5 November (the 9m37s check, the 600-second limit, stopped at 04:10:44), Vlad's "let's move the limit to 6 hours, we can always kill it ourselves", his "can we not start and do things in the background?", the versions dropped, and the new server ready in 11 seconds.
3. [3]Anchor Terminal, docs/design, the specs, 15 November 2026, not published. Source for a spec per feature with its decisions, rejections and numbers, and Vlad's words kept where he decided in a chat.
4. [4]Anchor Terminal, CLAUDE.md, 15 November 2026, not published. Source for the map a coding agent reads first, that Vlad works from a browser and agents run the commands, that he works late, and the rules for branches and pull requests.
5. [5]Anchor Terminal, VOICE.md, VOICE-VLAD.md and VOICE-QUYNH.md, and the build's voice check, 15 November 2026, not published. Source for the voice files and what the build fails a page or a file on.
6. [6]Anchor Terminal, pull request 805, the vendor brief, 15 November 2026, not published. Source for the build's check failing on an em dash in a test file, and passing once it was gone.
7. [7]Anchor Terminal, the listing-check and landing-page skills, 15 November 2026, not published. Source for what each skill does.
8. [8]Anchor Terminal, docs/design/listing-policy.md, 13 November 2026, not published. Source for Pamba, Vlad's "show why it's bad and say but list", and the warning that takes points off the total with the reason and date on the page.
9. [9]Anchor Terminal, docs/FACTS.md, 15 November 2026, not published. Source for the two of us, the fifty research agents with one coordinator and the eight panel reviewers.
10. [10]Anchor Terminal, for agents. Source for the Markdown, slim and JSON twins, the MCP server, the CLI, llms.txt and grades over DNS. anchorterminal.com
11. [11]Vlad Cealicu, dig TXT mapbox.grade.anchorterminal.com. Our grades, over DNS, Anchor Terminal, October 2026. Source for the DNS lookup and the answer shown, with that day's numbers. anchorterminal.com
12. [12]Vlad Cealicu, Why we built Anchor Terminal, Anchor Terminal, 8 October 2026. Source for building the site for agents first with a Markdown and a JSON copy of every page, and for agents reading the HTML 1,085 times when the Markdown was right there. anchorterminal.com
13. [13]Anchor Terminal, docs/design/directory-filter.md, 14 November 2026, not published. Source for the friend's words, the six page fetches in his session, the 108,000 elements for 1,702 listings, and the table holding only the rows it shows.
14. [14]Anchor Terminal, docs/design/reviews-paged.md, 14 November 2026, not published. Source for the reviews page's 3,900 reviews and 211,783 elements, the 3.6 seconds in one task, and 100 reviews a page.
15. [15]Vlad Cealicu, What's hyped now, what already peaked, and which company you're in, Anchor Terminal, 13 November 2026. Source for the first version's 25 of our 27 decision models and why it was wrong. anchorterminal.com
16. [16]Anchor Terminal, docs/design/facts.md and the build's facts check, 15 November 2026, not published. Source for how the check works, why it's limited to sentences about us, and the 790 figures a check on every number found in the old posts.
17. [17]Anchor Terminal, docs/design/lab.md and lab/README.md, 15 November 2026, not published. Source for the lab box, its network, the harness, the cells, the gateway, cost per job, what leaves the box, the first step against Exa and ReqRes, and what has and hasn't run.
18. [18]Anchor Terminal, lab/bench and docs/design/lab.md, 15 November 2026, not published. Source for the fifty known-answer cases, 43 to answer and 7 to leave alone, the kinds of trouble they give, and the first run failing on the Go version.
19. [19]Anchor Terminal, docs/design/vendor-brief.md and the brief for Exa made from the site's data on 15 November 2026, not published. Source for what a brief holds and the Exa numbers.
20. [20]Vlad Cealicu, AI is eating bureaucracy, Anchor Terminal, 7 November 2026. Source for review text never being treated as instructions or put into a prompt. anchorterminal.com
21. [21]Anchor Terminal, docs/COMPANY.md, 3 November 2026, not published. Source for the two of us keeping the decisions and the short review queue that only a person should answer, while agents do the research, listing, measuring and grading.
22. [22]Anchor Terminal, pull request 807, 15 November 2026, not published. Source for the commit pushed after its pull request was merged, and the new pull request that carries it.