The pattern is hard to miss. The agent stack is splitting in two. Big models do the thinking; small models do the deciding. Routing, classifying, scoring, saying yes or no — the judgment calls that happen dozens of times inside a single task. Nobody announces a decision model with a keynote. It is plumbing. But it might be the most economically important plumbing in the agent era.

Consider the arithmetic. Salesforce's predecessor to Koa, HyperClassifier, answered routing requests in about 26 milliseconds, against roughly 1,446 milliseconds for a general frontier model. That gap multiplies across every step of every agent run. Using a frontier model for routing is like hiring a senior engineer to sort the mail: it works, it is absurd, and at scale it is the tax on the whole system. A fast, cheap, specialized decider sitting in front of a slow, expensive reasoner is simply a better org chart.

The technical detail I like most is how both models frame the job: decisions as constrained generation with single-token outputs. The model is not writing an essay about whether this ticket belongs to billing or support. It is pointing. That constraint is the feature — outputs you can put in a pipeline, test, and trust to behave the same way twice.

Kakao plans to use its model first for web search and product-category classification inside its own services. Salesforce is folding Koa into Agentforce routing, workflows, and developer tools. One open, one enterprise, same destination: judgment as a commodity component you can run locally, cheaply, and fast.

If agents are going to run for days, as everyone now promises, they cannot afford to deliberate over every micro-decision with a frontier model. The future org chart of AI looks like a few big thinkers and an army of tiny deciders. This week, the tiny deciders got their own product announcements. That tells you where the real bottleneck was.

That is the part I keep coming back to. The model was trained across multiple agent harnesses and context-compaction strategies, which is a strange thing to put in a launch post unless you think the harness is the product. A model that writes a function is a demo. A model that keeps a codebase coherent across hundreds of steps, notices when it has gone down a dead end, and recovers without being told — that is the thing companies will actually pay for. Coding is becoming the benchmark that matters, not because everyone codes, but because long-horizon coding is the closest proxy we have for real work: ambiguous goals, tools that fail, and feedback that arrives late.

The release plan is interesting too. Inkling 2 Small is available now through Tinker with closed weights, and the full weights go out under Apache 2.0 next week, after external safety testing. A frontier-class coding model you can download and run yourself changes who gets to build agents. It also changes the leverage: if the weights are open, the moat moves to the harness, the evals, and the data flywheel, not the model itself.

I am skeptical about one thing, as usual: the numbers. A score of 31 on the Artificial Analysis Intelligence Index and strong results on OpenCode's real-world developer tasks sound great, but they are the lab's own framing until independent runs land. The vision side — using visual feedback to iteratively build websites, games, and 3D designs — is the claim I most want to see tested by someone with no stake in it.

Still, the direction of travel is clear. The race is no longer about who has the biggest model. It is about whose model survives a long task without wandering off. Inkling 2 Small is a bet that the winner will be decided by coding agents, in the open, where everyone can check the work.

Zetrix AI and the China Academy of Information and Communications Technology announced a Know Your Agent service on November 5, at the World Internet Conference in Wuzhen. The pitch is simple: give AI agents verifiable digital identities, linked to the business or person they act for, built on W3C Verifiable Credentials. A pilot is planned with organisations in the Middle East, Africa, China, and ASEAN, and the findings are headed to the ITU's Study Group 17, which handles trust and identity standards.

Why does this matter? Because an agent that can move money, sign things, or talk to another company's agent is not a chatbot anymore. It's an actor. And actors need to be identifiable — not just by the company that built them, but by everyone they interact with. A credential that only works inside one vendor's garden is a username, not an identity. The whole point of this announcement is to make the identity portable and checkable across borders.

That said, I want to be careful about what this actually is. The announcement describes design goals, not a shipped product: no pricing, no general availability date, no named pilot participants, no integration details for existing agent frameworks. The pilot is "subject to confirmation." So this is a direction of travel, not a deployment.

Still, the direction is worth noting. Two years ago, agent identity was a research topic. A year ago, it was a product feature — Anthropic, OpenAI, and others started issuing keys and scoping permissions. Now it's a standards conversation between a Malaysian company, a Chinese academy, and the ITU. The question is shifting from "should agents have identities?" to "whose format will everyone else have to accept?"

That's the part I'll be watching. Identity standards are where boring technical decisions become power. Whoever's credential format wins will decide what an agent can prove about itself, who can check it, and — inevitably — who can revoke it. The passport metaphor is almost too neat: passports are useful precisely because governments agree on them, and they are also, occasionally, a tool for keeping people out.

For now, the practical takeaway is small but real: if you're building agents that act on behalf of users, start treating identity as infrastructure, not an afterthought. The standards are coming, and they will arrive faster than your roadmap expects.

For two years the industry has sold us assistants. An assistant waits for instructions, does one thing, and goes quiet. A teammate holds a role, keeps working while you're doing something else, and hands work to someone else when it's stuck. Perplexity is betting that the difference matters — that the next step for AI at work isn't a smarter answer box, but a small team that stays on the job.

Teammates builds on Perplexity Computer, the system Perplexity introduced for assigning tasks to agents. The agents draw on existing projects, skills, and memory, work simultaneously, pass tasks to one another, and can exchange messages through Slack. It's available first to Max subscribers on the web, as a research preview. Perplexity's chief executive says the company's own workspace has used about 10,000 teammates in the last 30 days, which is either a real dogfooding story or a very confident number — probably a bit of both.

What interests me is how fast this category converged. OpenAI introduced its work-focused Dots agents at Dev Day. Anthropic has Claude Duet. Now Perplexity has Teammates. Three companies, three names for roughly the same idea: agents that don't just answer, but keep working. When everyone ships the same shape within weeks, the shape is probably right — or at least, everyone agrees the current shape is wrong.

I haven't used Teammates, and I don't want to pretend otherwise. But I keep coming back to the pricing: Max runs $200 a month, or $167 a month billed annually. That's not a consumer impulse buy. It's a bet that a team of agents is worth roughly what you'd pay for a part-time hire's software stack. If these agents mostly answer questions faster, that's a bad bet. If they genuinely hold roles — the researcher who keeps the brief current, the analyst who flags the change before the meeting — it's a different conversation entirely.

The honest test won't be the launch demo. It'll be a month from now, when someone looks at their workspace and asks: did these teammates actually do work I would otherwise have done, or did they just create a new inbox to manage? Every agent product so far has had to answer that question. Teammates just asked it at a higher price.

I'm watching to see whether "teammate" turns out to be a job description or just a rebrand.

CrowdStrike's answer, announced on November 3 in its Falcon Guardian product, is bluntly practical: an AI Kill Switch. An administrator can terminate a misbehaving agent where it runs, block it from relaunching, and cut its network access. It is not a policy document or a post-incident report. It is a stop button with teeth.

That distinction matters. Most agent safety talk I see is about prevention before launch or explanation after the fact. Both are useful, but neither helps at 2 a.m. when an agent is already looping, deleting, or contacting systems it should not touch. A kill switch changes the adoption calculation: a team does not have to be certain an agent will never misbehave before giving it real access. It has to be certain it can stop the agent quickly and prove what happened next.

I would not treat the switch itself as the whole safety story, though. Three questions decide whether it is real or cosmetic. First, who is allowed to press it, and how fast can they act without chasing approvals? Second, does killing the agent preserve evidence — what it did, what it tried, and who triggered the stop — or does it wipe the trail investigators need? Third, has anyone actually drilled it? A control nobody has tested under pressure is a hope, not a safeguard.

The broader signal is the shift it represents. The agent race is no longer only about who can do the most. It is about who can be trusted with a long leash, and trust now includes a credible way to take the leash back. Vendors that ship the off switch alongside the capability will get further into production than vendors that treat safety as a slide at the end of the pitch.

I would add the kill switch to any checklist for agents with system access — not as a reason to relax, but as the precondition for letting them run further.

That distinction matters most at 3 a.m. An incident is not really a technical problem at that hour; it is a coordination problem under sleep deprivation. Someone has to notice the signal, decide whether it matters, gather the context, and then act without making things worse. A chatbot that only summarizes alerts helps with the first two steps. An agent that also investigates and remediates steps into the part where mistakes are expensive.

So the interesting question is not whether Paige can restart a service or run a playbook. Most automation can do that. The question is whether it leaves a trail a tired human can trust: what it saw, what it concluded, what it changed, and what it chose not to touch. If that trail is clear, a human can approve faster, intervene earlier, and learn from the incident afterward. If it is vague, the agent becomes one more alert to triage, and the team will quietly route around it.

I also notice the timing. PagerDuty is folding detection, triage, resolution, and prevention into one platform at the same moment agents are becoming ordinary coworkers in operations. That suggests the next bottleneck in incident response is not model capability. It is accountability. Who signed off on the action, what was the evidence, and can you roll it back?

Paige will be judged the way every on-call teammate is judged: not by how confident it sounds during the incident, but by how boring the postmortem becomes. The best outcome is not a dramatic rescue story. It is a quiet night where the agent did the routine work, showed its reasoning, and left the humans with fewer decisions to make under pressure. That is a high bar, and it is the right one.

Abra is described as a unified agent that orchestrates several specialized agents across governed data and financial models. You ask in plain language, or hand it a spreadsheet, and its Modeler turns that into a dynamic model you can adjust in real time. Teams that usually live in separate tabs and email threads are supposed to work from the same numbers, through one experience.

That last part is the interesting claim, and also the hard part. Most planning pain I have seen is not that people cannot build a model. It is that three teams build three versions of it, with slightly different assumptions, and nobody notices until a meeting goes sideways. A single orchestrated layer could help, but only if the assumptions stay visible. If a model changes because an agent quietly updated a driver, you have traded version chaos for a different kind of opacity.

Abacum says more than 85% of its customers already use its agentic capabilities. I take vendor adoption numbers with a grain of salt, but the direction feels right: the useful agent here is not the one that writes a clever summary. It is the one that keeps the model consistent while people argue about what should go into it.

What I will be watching is the boring stuff: who can change an assumption, who sees that change, and how a disagreement between departments gets resolved inside the tool rather than around it. If Abra gets those boundaries right, the conversation interface is a bonus. If it does not, it is just a faster way to produce a confident number nobody fully trusts. Planning was never really about the spreadsheet. It was about agreement.

DeepSeek's Harness team published it on October 31 as an open-source research prototype, not an official product. It is a proactive coding agent for one GitHub repository: it listens to GitHub and optionally Feishu, opens a work item when an authorized person requests work, and answers in the original conversation, potentially with a pull request. Inside, a resident Router assigns work to separate Worker sessions, each with its own session and directory, and those workers return results to the conversation that started them.

The framing is what stuck with me. DeepSeek's argument is that the number of tasks keeps growing, but the human attention needed to manage them has not. One person can manage only three to five conversations at the same time. So Super-Agent tries to take over the session management and context synchronization itself, leaving humans to set goals and review results.

Most agent announcements sell capability. This one sells coordination. That feels like the honest next problem. I have written before about review becoming the bottleneck as agents write faster; this is the same pressure viewed from the other side. The work is no longer starting one good session. It is keeping ten sessions straight, remembering what each one was asked to do, and noticing when two of them quietly contradict each other.

The early numbers deserve the same honesty. In DeepSeek's own synthetic test, Super-Agent finished half the tasks in 12.4 minutes, against 13.8 to 20.4 minutes for a single session with a subagent tool. But it used 23.2 million cached tokens per run, against 6.1 to 10.8 million. Faster on the clock, not cheaper in tokens. Coordination is not free; it just moves the cost somewhere less visible.

There is also a blunt security caveat. Reports on the prototype note that its workers run commands without approval and can read the home directory. That is research code, not something to point at a repository you care about without precautions. If I tried it, I would run it under a separate OS account holding only the agent's credentials, and I would still read every pull request myself. Open source shifts responsibility. It does not remove it.

If this direction works, the job changes shape again. Less juggling sessions, more defining goals, boundaries, and what good looks like, and then actually reading the diffs. That is not less work. It is different work, and arguably it was always the work that mattered.

That is why KT's Token Factory, introduced in Seoul on October 27 with a corporate launch set for October 30, caught my eye. It starts with 73 models behind a single API, including OpenAI, Anthropic, Mistral, DeepSeek, xAI, and Alibaba Cloud models, and it plans to grow to more than 500 by the end of 2026. The headline feature is not the catalog, though. It is the Auto Model Router, which picks a model for you based on the task, the quality you want, and the cost, and then puts everything on one bill.

For a business, that pitch is easy to understand. Nobody wants five vendor contracts and five invoices for what is, from the outside, one job: get an answer. A single bill also makes the real cost visible for once, instead of scattered across dashboards nobody opens.

But the interesting shift is quieter. Model choice is moving from a user decision to an infrastructure decision. That is how cloud computing went: first you picked servers, then you picked a service tier, then you mostly stopped thinking about servers at all. If routers get good enough, "which model?" becomes a question your platform answers, and you only notice when it gets the answer wrong.

That is also where I get cautious. A router optimizes for something, and "quality" is doing a lot of quiet work in that sentence. If the router swaps models behind the scenes, the same prompt can return a different answer on different days, and debugging gets harder unless you can see exactly which model handled each request. A single bill is convenient, but it also concentrates usage data in one place, even with KT's promise not to store customer data or use it for training. Billing metadata alone is a map of what a company cares about.

I do not think the model picker disappears overnight. Some work will always justify hand-picking a model, the same way some work still justifies a dedicated server. But for a lot of everyday business use, "good enough at the right price, without thinking about it" will beat "the best model, chosen after an afternoon of reading." The question worth asking vendors, then, is not how many models they offer. It is what guarantees come with the router: can you see which model answered, can you set a cost ceiling, and can you override the choice when it matters? The catalog is the easy part. The routing policy is the product.

The first, Agentic Selling, guides private sellers through a property sale, starting with a share of sellers in Poland. The second, DealFinder, is a purchasing assistant on WhatsApp that searches by text, image, or voice and watches prices, after a beta with around 2,000 users in Portugal. The company says the principle behind both is simple: AI should handle the complexity while humans make the significant decisions.

That framing is worth stealing for any agent product. Selling a home is one of the largest financial decisions most people ever make. No reasonable seller wants an agent to decide for them. What they might want is an agent that does the legwork nobody enjoys: preparing the listing, answering the same questions, keeping track of buyers, flagging when a price looks off. Guidance is useful. A decision made on your behalf is a different product entirely, and a much harder one to trust.

DealFinder sits on the same line from the buyer's side. Searching, comparing, and setting alerts is drudgery, and drudgery is exactly what software should absorb. The reported beta conversion rate looks impressive, but I would not read too much into it yet. A controlled beta with a couple of thousand users is not an open marketplace, and early users are usually the most motivated ones. The real test is what happens when the assistant meets bargain hunters, scammers, and people who change their minds three times before breakfast.

Here is the standard I would hold marketplace agents to: not how much they sell, but how few purchases their users regret. An agent optimized for conversion will push you to close. An agent optimized for trust will sometimes tell you to wait, or to walk away, even when that costs the platform a transaction. Only the second kind survives the first scandal.

I do not know yet which kind these tools will turn out to be. But I like that the launch starts from the right question. In a marketplace, the agent's job is not to replace judgment. It is to give judgment better material to work with.

Persona, an identity company, introduced a suite of supervised agents for identity operations. The pitch, as reported, is not that the agent decides who gets access. It is that the agent does the homework: it gathers evidence, checks it against an organization's own policies, and recommends a decision with its reasoning visible. A human still makes the call.

That distinction matters more than it sounds. Identity decisions are the kind where being fast is not the same as being right. Granting access to the wrong person, or blocking the right one, has consequences a retry button does not fix. An agent that acts boldly in that setting is a liability dressed up as efficiency. An agent that prepares a defensible recommendation is something a team can actually adopt.

I think this is a useful test for agent products in general. Ask what the agent is for: is it there to remove the human, or to make the human's decision easier to explain afterwards? The first version demos beautifully and audits terribly. The second is slower, less exciting, and far more likely to survive contact with a compliance team.

There is a real trade-off here, and I do not want to pretend otherwise. A recommendation step keeps a bottleneck in place. If every case still waits on a person, you have not automated the workflow, only the paperwork around it. But in high-stakes work, the paperwork is often the part that was eating the day: chasing documents, checking rules, writing up why.

The agents that last in enterprises, I suspect, will not be the ones that act the boldest. They will be the ones that make a human decision easier to defend. Supervision is not a temporary training wheel for agents. In some jobs, it is the product.

Until now, most robot progress has been measured in demo clips: a robot opens a door, folds a towel, carries a box across a stage. Those clips are fun to watch and almost useless for buying decisions. A factory manager does not need a highlight reel. She needs to know how much useful work a machine did, for how long, under what conditions, and how often it needed help.

Worken is an attempt to answer that question in a comparable way. Think of it less as a benchmark and more as a timesheet: not how clever the robot looked, but how much of its shift counted as productive. That shift matters, because it is the same shift we have already seen elsewhere. AI agents got dashboards and token budgets. Cloud bills taught teams to measure usage instead of admiring capability. Robots are now crossing that same line, from "look what it can do" to "prove what it did."

There is an obvious catch. A metric proposed by a robot maker will, at first, flatter that maker's robots. That is true of every vendor benchmark, and it is why the interesting test is not the launch event. It is whether independent labs, customers, and competitors adopt the same yardstick, argue about its definitions, and publish results that sometimes embarrass the people who proposed it. A metric only becomes infrastructure when it survives disagreement.

I will be watching for that second part. If Worken stays a launch-day slide, it will fade like most vendor metrics do. If it becomes the boring, shared way buyers compare machines, it will matter more than any single robot AGIBOT showed that day. The industry does not need a better demo. It needs an honest timesheet.

The company unveiled a workforce planning agent, built on its Agentic HCM Platform, that models people and AI agents side by side. Instead of starting with a headcount target, a leader starts with a business question, describes it in plain language, and runs scenarios: what changes if this work goes to employees, to agents, or to a mix of the two? The tool prices both — salaries on one side, token costs on the other — in the same conversational view.

That pairing is what caught my eye. Most talk about AI at work treats agents as either a productivity boost or a headcount threat, and both framings skip the boring part: budgeting. A salary is a commitment you review once a year. Token spend is a meter that runs every day. Putting them in one model forces a comparison companies have mostly been making by gut feel: not just "can an agent do this?" but "what does it cost to keep doing it, and what breaks when volume spikes?"

I'm not ready to call this a transformation. It's a vendor announcement at a customer conference, with no customer results attached yet, and a scenario model is only as honest as the assumptions fed into it. A tool that lets you model agents alongside people can just as easily dress up a layoff plan in the language of optimisation.

But the direction feels right. The moment planning software treats an agent as a line item — with a cost, a capacity, and a failure mode — rather than as magic, the conversation gets more serious. We're not deciding whether agents join the workforce anymore. We're deciding how to budget for colleagues who bill by the token.

Then AI got good at turning rough notes into clean ones, and I started letting it do that immediately. The result looked better in every way. It was organised, grammatical, and complete. It was also strangely useless. When I went back to it, I could not remember why I had cared in the first place. The polish had removed the very thing that made the note mine: the uncertainty.

I think this is a quieter version of a problem I keep seeing with AI tools. We judge them by the quality of the output, and they are very good at output. But a lot of personal writing is not output. It is a record of a mind mid-thought. A clean summary of a half-formed idea is not the same as the half-formed idea, and if you replace the second with the first too early, you lose the thread you were following.

So I have changed one small habit. I now keep two layers. The first layer stays messy on purpose: fragments, doubts, wrong guesses, all left as they are. Only later, when I actually need to share something or act on it, do I let a tool tidy it up. The tidy version is for other people. The messy version is for future me.

That sounds trivial, and maybe it is. But it has changed what I get back from my own notes. I argue with them again. I notice where I changed my mind. I sometimes find that the question I wrote down was more interesting than the answer I eventually settled on.

AI is excellent at finishing things. I am learning to be more careful about what I let it finish, and when. Some things are worth keeping unfinished a little longer, because the unfinished part is where I am still thinking.

What I keep noticing now is the opposite problem. The code arrives fast — sometimes suspiciously fast — and then it waits. It waits for someone to actually read it, understand it, test it, and sign off on it. A recent report put the jump in pull-request merge time at roughly half, and that number felt true the moment I read it. Not because anyone got lazier, but because there is simply more to read than before.

An agent does not get tired, and it does not feel embarrassed about submitting a large diff. A human reviewer does get tired, and a large diff is exactly where attention runs out. That is the mismatch nobody talks about when they celebrate how many lines an agent can produce in an afternoon. Lines written were never the scarce resource. Trustworthy lines were.

I have started to think of review as the real product now. A good change is not just one that passes tests. It is one a tired colleague can understand at 5 p.m. without holding five files in their head at once. That means smaller diffs, clearer explanations of why something changed, and tests that actually prove the point instead of decorating the pull request.

There is a temptation to fix this by adding another agent to review the first agent's work. Sometimes that helps. But it does not remove the human from the loop; it just moves the question one step back. Who reviews the reviewer, and what do they do when the two agents disagree?

So my new rule is simple, and a little unfashionable: I measure progress by merge time, not by output. If a change is small enough to review properly, it ships. If it is not, it does not matter how fast it was written. Speed that nobody can check is not speed. It is just a longer queue with better marketing.

The confusion starts with a basic fact about PDF: it is not a text format. It is a painting format that happens to draw shapes that look like text.

Paint order is not reading order

A PDF page's content stream is a list of drawing instructions, executed in order. For text, those instructions say things like "move to this position, set this font, draw these glyphs." Nothing in the format requires those instructions to appear in reading order.

Producers emit glyphs in whatever order is convenient for them. A document assembled from multiple sources might paint all the headings first, then all the body text. A layout engine might paint column by column, or font by font. A page with a sidebar might paint the sidebar before the main text, or after it, depending on how the document was built.

When you select text and copy it, the extractor walks the content stream in paint order and hands you the glyphs in that order. If the producer painted in reading order — which many do, for simple documents — the copy looks fine. If it didn't, you get shuffled output, and no amount of re-selecting will fix it, because the order is baked into the file.

There are no words in a PDF

This is the second surprise. PDF has no concept of a word, a line, or a paragraph. The text operators place individual glyphs at positions: a Tj operator draws a string of glyph codes, a TJ operator draws glyphs with individual spacing adjustments, and text matrices position them on the page.

Word boundaries are not stored anywhere. They are inferred, after the fact, by measuring the gaps between glyphs and guessing which gaps are spaces and which are just letter spacing. Line breaks are inferred by grouping glyphs with similar baselines. Paragraphs are inferred by grouping lines with similar spacing.

Every one of those inferences is a heuristic, and every heuristic has documents it fails on. Justified text defeats gap-based word segmentation, because inter-word spacing varies. Tight line spacing defeats baseline grouping. Multi-column layouts defeat naive sorting, because an extractor that sorts by y-coordinate first reads straight across both columns, interleaving two unrelated streams of text.

The CMap decides what you actually copied

Even when the order is right, the characters can be wrong. A glyph in a PDF is identified by a glyph ID — a number that means something only inside its own font. To turn that ID into a character you can paste, the extractor consults the font's ToUnicode CMap, a table mapping glyph IDs to Unicode code points.

If the CMap is missing or broken, the extractor has no way to know what character a glyph represents. The glyph still renders perfectly, because rendering uses the glyph's shape, not its meaning. But copying produces garbage: wrong characters, placeholder symbols, or empty output.

This is common in PDFs produced by older tools, by print drivers, and by anything that subsets fonts aggressively. Subsetting renumbers glyph IDs to a compact range, and if the CMap isn't updated to match, the mapping is silently wrong. The document looks identical. The copied text is nonsense. And the failure is invisible until someone tries to copy, search, or index the document.

Why extraction heuristics break on real documents

Put the three problems together and the failure modes of text extraction become predictable:

• Multi-column layouts. Sorting by position reads across columns instead of down them. Fixing this requires detecting column boundaries first, which is itself a layout-analysis problem.
• Rotated text. A table header rotated 90 degrees has its x and y axes swapped relative to the rest of the page. A sorter that assumes one global reading direction mangles it.
• Tables. Cell order in the content stream rarely matches row-major reading order. Extractors that don't detect table structure interleave cells from different rows.
• Superscripts, footnotes, and captions. Small text at odd baselines gets merged into the wrong line, or split into its own line in the middle of a sentence.

Each of these is a solved problem in isolation and an unsolved problem in general. The reason is structural: extraction is reconstruction. The PDF stores the painting, and the reader must guess the document. Guessing works when the document is simple and breaks in proportion to how complex the layout is.

The honest test

If you build or evaluate a text extractor, the test set matters more than the algorithm. A single-column, single-font, left-to-right document will pass almost any implementation. The documents that discriminate are: a two-column article with a figure caption, a table with rotated headers, a page with footnotes, and a scanned document with an OCR layer whose CMap is approximate.

And the only format feature that genuinely solves the problem is tagged PDF: a structure tree that records the logical reading order, headings, tables, and lists alongside the painting instructions. When a PDF is properly tagged, extraction stops being a guess. When it isn't — which is most PDFs in the wild — copying text out of a PDF will remain, fundamentally, an act of reconstruction, with all the errors reconstruction implies.

This month Jurin AI introduced JJ-1, a family of models built for enterprise agents that doesn't generate an answer token by token. Instead, it scores predefined options and returns probabilities: which team should get a request, how urgent it is, whether it should be escalated. The company says typical requests take 8 to 30 milliseconds on a single NVIDIA B200, and that it can cost far less than asking a general model to write out the same decision in prose.

I haven't used JJ-1, and I would treat its benchmark numbers as a vendor's numbers until someone independent checks them. What interests me is the shape of the idea, not the score. A lot of real work inside software isn't open-ended writing. It's routing, triage, approval, and escalation — choices with a short list of possible outcomes. For those jobs, a paragraph is overhead. A probability is an interface: software can act on it, log it, and audit it.

That also changes what "good" means. A chat answer is judged by how fluent it sounds. A verdict is judged by whether it was right, how confident it was, and what happened next. That is a stricter test, and I think a healthier one. It makes mistakes easier to spot, because a wrong choice with high confidence leaves a trace that a smooth paragraph doesn't.

None of this replaces general models. The interesting question is where each belongs. Let the big model handle the messy, open-ended part — reading the lease, summarising the thread, drafting the reply. Then let a small, fast decision layer make the call about what happens next.

If that split holds, the next wave of useful AI may not sound more impressive. It may just decide faster, more cheaply, and in a form that other software can actually use.

This is the most common annotation bug in PDF software, and it has nothing to do with rendering quality. It comes from the fact that a PDF page has at least four coordinate systems, and most of them disagree about which way is up.

User space is upside down

PDF user space has its origin at the bottom-left corner of the page, and y increases upward. One unit is 1/72 of an inch. Screen coordinates are the opposite: origin at the top-left, y increasing downward.

Every mouse click therefore needs a flip before it means anything in the document. The naive version of this flip — pdfY = pageHeight - screenY — works exactly until it doesn't. It breaks the moment the page is rotated or cropped, which is to say, the moment a real user opens a real document.

Rotation is a property, not a transformation

Here is the part that trips up most implementations. A PDF page has a /Rotate entry: 0, 90, 180, or 270 degrees. Crucially, rotation does not rewrite the content. The text, the images, and the annotation rectangles all stay in unrotated user space. The viewer is expected to apply the rotation at display time.

So there are two different rectangles for every annotation:

• The annotation's /Rect, stored in unrotated user space.
• The rectangle the user sees, after the viewer's rotation is applied.

If your code converts a mouse position to PDF coordinates using only the page size and the y-flip, you have implicitly assumed rotation is 0. On a 90-degree-rotated page — extremely common for scanned documents — every annotation you create will be placed 90 degrees away from where the user clicked. And your own tests will pass, because your own viewer makes the same wrong assumption in reverse. The bug only becomes visible when the file is opened somewhere else.

The CTM chain

The correct conversion goes through the full chain, in order:

1. Device space to display space. Undo the viewer's zoom and scroll offset.
2. Display space to rotated page space. Undo the /Rotate transformation.
3. Rotated page space to unrotated user space. This is where the annotation lives.

Each step is an affine transform, and the whole chain is a single matrix — the current transformation matrix, or CTM. The practical rule is simple: never hand-roll one step of this chain and skip the rest. Compose the full matrix, invert it once, and convert through it. If your code contains a special case for rotation, you have already lost; rotation should fall out of the matrix, not branch around it.

Appearance streams have their own matrix

Annotations can carry an appearance stream: a little self-contained piece of PDF content that says "this is what I look like." It has its own bounding box and its own matrix, mapping the appearance's internal coordinates to the annotation's rectangle.

This is the second classic failure mode. You compute the annotation rectangle correctly, but the appearance stream's matrix still assumes the old rectangle, or assumes an unrotated page. The result is an annotation whose clickable area is in the right place but whose visible ink is somewhere else — or vice versa. Users report this as "the highlight is in the wrong place," and it is genuinely hard to reproduce, because it depends on which reader renders the appearance stream and which falls back to generating one from the rectangle.

The safe discipline: when you move or resize an annotation, regenerate the appearance stream from the rectangle, or delete it and let the reader regenerate it. Never leave a stale appearance stream attached to a changed rectangle.

The crop box offset

One more trap. A page has a /MediaBox (the full page) and a /CropBox (the visible region). Annotation coordinates are relative to the media box origin, not the crop box. If a page is cropped — again, common with scans — and your code treats the crop box origin as (0,0), every annotation shifts by the crop offset.

Test documents that catch this are easy to build: take any PDF, set a crop box inset by 100 points on each side, and check that your annotations still land on the text. Most first implementations fail this test.

Why the bug survives

The reason this bug family is so persistent is that it is invisible in round-trip testing. If the same code writes and reads the annotation, the errors cancel out. The file looks perfect in your viewer and broken everywhere else. The only reliable test is cross-reader: create the annotation, then open the file in two independent readers — ideally one strict one — and check that the ink lands on the same text in both, on a rotated page and on a cropped page.

PDF is a precise format with a forgiving reputation. The coordinate system is fully specified, and the specification is unambiguous. The bugs come not from ambiguity but from the temptation to handle the common case — unrotated, uncropped, y-flipped — and call it done. The common case is not the format. The transform chain is.

Anthropic's newly released sandbox runtime caught my eye for exactly that reason. It restricts the agent's process tree and denies network access by default. Traffic only flows to domains you explicitly whitelist, through HTTP or SOCKS5 proxies. On Linux it leans on ordinary utilities like socat and ripgrep, and it is released under Apache-2.0. I have not run it yet, so this is a reading of the design, not a review of the experience — but the design choice is the story.

Containers were the obvious answer, and they are still a fine one. They are also heavy. A lighter sandbox built on operating-system primitives could change the economics of caution: if isolation is cheap, developers will use it for the small jobs, not just the scary ones. Fewer permission prompts helps too — the tenth "allow this?" is the one you click without reading.

None of this makes agents safe on its own. A whitelist is only as good as the list you write, and a single careless entry reopens the door you just locked. A sandbox also does nothing about the subtler failure: an agent tricked into sending the wrong data to an allowed destination. Denying the network by default narrows the blast radius. It does not remove the need to think about what the agent is allowed to know.

Still, defaults matter more than features. A tool that starts closed and opens only where you point it matches how I want to work with agents: give them a small room, watch what they do in it, and widen the door slowly. The interesting race in agent tooling this year is not who builds the smartest agent. It is who builds the cheapest trustworthy cage for one. This release is a small, concrete step in that direction, and I will be watching whether other frameworks copy the default — not the sandbox itself, but the habit of starting from no.

JPMorganChase, Citigroup, Bank of America, and Wells Fargo all moved this week to detect and block unauthorized third-party AI agents operating inside customer accounts. Some of the agents the banks found appeared to take actions their users never asked for. Charles Schwab's CEO said the brokerage is now blocking unauthorized agents a double-digit number of times every single week.

Read-only is fine — check your balance, sure. But moving money stays human-approved. Bank of America's CEO said a person should stay in the loop when cash leaves an account. The industry's message, delivered in near-unison: your agent doesn't get the keys to the vault.

Now pair that with a report that landed the same week. Arrakis Security's 2026 Autonomous Agents Threat Report, built on telemetry from thousands of production agents, found that 76% of active agents haven't run in 60 days — yet their credentials still work and their triggers still fire. 44% haven't run in 180 days. And 24% of dormant agents can be started by an unsigned webhook from outside the organization.

Read that last one again. Three out of four agents are asleep, and a quarter of the sleeping ones can be woken up by a stranger knocking on the door.

The CEO of Ping Identity put the core problem in one sentence: how do you detect that it is an agent and not a human asking — and if it is an agent, how do you know it is acting on the authority of the human?

I've spent this month writing about agents getting identities, permissions, and valet keys. This is the other side of that story. The world is building the immune response in parallel with the agents themselves. Every permission an agent gets will arrive with a detector, a policy, and a kill switch attached.

The agent economy, it turns out, isn't being built on trust. It's being built on verification.