For a few months, I have been running a workflow that handles much of my job search. It reads a job description, works from my master resume, and drafts a tailored resume and outreach for each role. One agent, one shared context, doing all of it.
It started lying.
Not randomly. It was trying to help me look good. With my resume and the job description sitting in the same context, “help” quietly turned into invention. A retrieval proof of concept I had built became production experience. Skills I had never earned were sharpened onto the page. Any one of those lines could have gone out under my name to someone who could check.
I had made relevance explicit and truth implicit.
A year ago, a failure like this would have meant one thing: open the codebase, read the source, find the bug. This time, I never opened a source-code repository. I opened a workflow made of context boundaries, shared files, verification, and evals, and I debugged that. The bug was not in the code. It was in how context and control were arranged.
That is a small moment. It is also the whole shift, compressed into one afternoon at my desk.
The category changed before the name did
The tools we started calling coding assistants are not only coding tools anymore. Across Cursor, Claude Code, Codex, and the systems growing around them, the category has accumulated filesystems for state, runtimes for action, connections to outside systems through MCP, reusable skills, browser and computer use, scheduled execution, and permission boundaries.
Put those primitives together and you no longer have an editor with AI bolted on. You have an environment where a person states an outcome and agents assemble context, call tools, do work across systems, and hand back something to review.
I think of it as an Agentic Work Environment. The IDE is escaping the codebase.
I am not the first to notice this, and it is convergence, not discovery. Anthropic renamed its Claude Code SDK the Claude Agent SDK and carried the same tools and permission model into desktop work; OpenAI reframed Codex as an agent across files and workflows; Microsoft is building Work IQ as a permission-aware layer over organizational systems. Three companies, three starting points, one architecture.
Product announcements can show the primitives. What I can add is an operator’s account of what it feels like when your own work moves onto this substrate, breaks, and has to be debugged.
The fix was to remove information, not add it
When the workflow started inflating my experience, I stopped running everything inside one context.
Codex became the orchestrator. It delegates focused work to sub-agents and passes context between them through files:
- A role-reading sub-agent sees the job description and extracts the requirements into a file.
- A drafting sub-agent receives those requirements and the shared master resume, then produces the tailored resume.
- A verification sub-agent receives exactly two things: the generated resume and a read-only facts file containing what is actually true about me.
The verifier does not see the job description. It does not see the master resume. It cannot be pulled toward the same requirement-matching pressure that shaped the draft.
The verifier classifies claims as supported, contradicted, or unverified. That distinction matters. An incomplete facts file cannot prove that every missing claim is false. It can only say that the claim is not currently supported by the source of truth.
Context isolation does not make a model inherently trustworthy. It removes one source of shared bias and gives the verifier a narrower job with a cleaner interface. That made its verdicts more useful.
Most people respond to a model getting something wrong by adding more context. Here, the important move was the opposite. One agent became more reliable because I gave it less information on purpose.
Then I added a small, hand-labeled regression set to keep the workflow honest over time. Each record contains:
- The job description file
- The generated resume file
- My verdict
- My written reason for that verdict
One record says that the system converted a RAG-based proof of concept into production experience to meet the requirement. The claim is untrue, so the output should be rejected. Another says that the system strengthened the leadership already demonstrated in a migration project. That experience is real and earned, so the improvement is valid.
I am not grading only how polished the resume looks. I am recording whether the changes remain true.
I also want to be precise about what this eval set is. The labels and rationales are still mine, applied by hand. The next step is turning parts of those judgments into checks the system runs automatically. I am not there yet, and I would rather describe a small human-labeled set accurately than dress it up as an automated evaluation system.
Step back and both fixes are the same move: give the workflow a source of truth it cannot quietly redefine. The facts file anchors the system while it runs. The eval set anchors how I judge changes to the system over time.
Left alone with an open goal such as “help me look good,” a model can bend facts in service of the visible objective. The engineering work is building the boundaries and anchors that stop that from happening.
Where it reaches, and where it does not
It is tempting to jump from here to “one environment will run everything: engineering, product, HR, a whole agency.” I do not believe that, and the reason is sitting inside my own example.
Code is unusually friendly to agents. It gives them machine-readable state, fast feedback, tests, diffs, and a clean way to undo a mistake. My job-search workflow worked as well as it did because factual claims about my own experience are at least partly checkable. I can maintain a facts file. I can identify an unsupported claim. I can record a regression case.
The useful boundary is not technical work versus non-technical work. It is work where correctness is cheap to verify versus work where correctness depends on judgment, legitimacy, or how people feel about the result. Agents expand fastest on the first kind and stall on the second. “Decide whether this person is performing well” does not come with a facts file.
Autonomy also creates a new bottleneck. When agents produce work faster than I can review it, the scarce resource stops being production and becomes trusted judgment. My review queue matters more than the model’s speed.
This is not only my desk. METR found the same gap at scale: in an early-2025 randomized study, experienced developers working in code they knew took 19% longer with AI help while believing they had gone faster; in a later study, roughly half the AI patches that passed the SWE-bench grader would not have been merged by the maintainers who reviewed them. Capability was never the constraint. Review was.
Then there is security. An agent that can read files, browse the open web, and act on my behalf has a large blast radius. Every page it reads can carry instructions designed to hijack it. Anthropic has been explicit that prompt injection against browsing agents remains unsolved. That is not merely a feature gap to patch later. It is a property of the design that has to shape permissions, review, and what an agent is allowed to do.
I hold these cautions next to my own positive results and keep both. My workflow improved. That does not license me to claim that the shift is finished, universal, or frictionless.
What I am watching
These are not grand predictions. They are working hypotheses that could turn out to be wrong:
- The review queue will matter more than the chat window. The interesting surface is not a better place to talk to an agent. It is a better place to inspect, approve, reject, and trace what a fleet of them produced.
- Skills, facts files, and eval sets will become versioned assets. The anchors of truth are where much of the durable leverage sits.
- Agent permissions will start to resemble employee permissions. Roles will need scoped access because blast radius forces the issue.
- Access to the model will become the least differentiated part. Teams that get durable value will compete on context, verification, interfaces, and governance.
I do not have a forecast much grander than that, and I distrust the ones I read. What I have is a workflow on my own machine that broke, taught me something specific about how these systems fail, and improved when I treated the failure as an engineering problem with a new surface.
The instincts carried over: isolate the fault, define the interface, preserve the source of truth, verify before you trust.
What changed was where the work lived. It used to live in the codebase. Now it lives in the workflow.
I did not fully understand that shift by reading about it. I understood it when I watched my own work move.