We rewrote our website with our own Context OS. Here is what it actually took

Our website had too many words explaining why teams should need fewer words.

That's a slightly embarrassing brief to give your own Context OS. Also a useful one.

The job was to rewrite the core pages, keep the design, and make the offer easier to understand. The result went live on September 18, 2026.

We can show the copy, layout decisions, release checks, and changes to the system afterward. We haven't measured a conversion lift, search improvement, or time saving. This is an account of the work, including where the process still fell short.

We asked for a rewrite, not a new personality

The site needed to sound more like the business: a small team building useful systems, willing to experiment, impatient with work that creates more cleanup than output.

The existing colors, visual language, and writing guides stayed in place. Homepage, About, Pricing, services, Contact, careers, and shared copy were in scope. Most existing articles stayed as they were.

That gave the agent a problem and a boundary. It also left room to discover that a module belonged somewhere else, or that an explanation could be removed entirely.

We required backups before substantive edits and kept changes inside the Deadwater repository. Those were operating constraints for the assignment. They didn't need to become more copy on the website.

The agent used company context, writing guidance, the site implementation, and public research. Those sources had different jobs. A positioning brief couldn't establish what the contact form actually did.

That's context strategy in a practical setting: know which source belongs in which decision. Reading more material isn't the same as using the right material.

Nielsen Norman Group's research on reading online supported the direction toward scannable text and meaningful headings. It didn't choose our positioning or predict a conversion result for us.

Put recognizable work before the machinery

The homepage had been explaining the system before giving a buyer a reason to care. We changed the order.

These are actual before-and-after strings; the released hero's line break is shown as a space:

Location	Before	Released copy
Homepage hero	Content operations, rebuilt for AI.	More output. Less AI babysitting
Context benefit	Agent-ready context, not prompt glue	Stop explaining from scratch
Workflow benefit	Repeatable workflows with gates	Get out of the cleanup loop
Ownership benefit	Owned systems your team can inspect	Own what we build

The ownership card adds: “Keep the files, workflows, and instructions. Your team can inspect and improve them.”

Those nouns do useful work. A buyer can ask to see the files. “Operating layer” usually requires another paragraph before we get to the same conversation.

Contact became “Let's scope the work,” followed by the actual next step: an email follow-up to arrange a call. The form wasn't an instant calendar booking, so the copy shouldn't imply one.

GOV.UK's interface-writing guidance reinforces that habit: put important words first and remove unnecessary explanation. Pricing and scope stayed available because buyers still need them.

Shorter copy shouldn't make the purchase more mysterious.

The best hierarchy decision came from looking at the page

The Context OS hub-and-spoke diagram started in the pricing experience. Review moved it to the homepage, then made it the main landing feature.

The headline, paragraph, and buttons moved into a centered stack above it. We removed the heading, eyebrow, explanatory paragraph, and tags around the diagram. The visual could carry its own explanation.

The “Two ways in” module moved toward pricing, where the engagement choices belonged. Context OS became the first option and default selection.

Same design language. Different order of information.

That decision didn't come from counting characters. Someone looked at the result and recognized what deserved the first screen. The agent could then implement the direction across the page.

The diagram shows possible extensions of company knowledge into useful work. It isn't proof that eight integrations are running or eight outcomes have been achieved.

Each actual job still needs its workflow anatomy: inputs, actions, review, and a definition of complete. The site could express ambition without pretending that a diagram had already done the implementation.

Shipping meant finding out which website was actually live

The rewrite touched a working application: routes, shared templates, forms, a pricing selector, and interactive tools. A sentence being correct in a file was only part of the job.

Preserve a starting point you can use

We saved the relevant working state and a separate Git history bundle. Copied files matched saved hashes, and the pre-rewrite snapshot passed a production build with the installed dependencies.

Git bundles cover refs and reachable commits, not every uncommitted local file. We needed both forms of backup because the checkout wasn't empty of existing work.

That established recoverable source and history for this assignment. It wasn't a clean-machine disaster-recovery test of every external service.

The local starting point also lagged production. The release had to preserve changes already on the production branch while adding the approved rewrite.

Git's comparison modes let you inspect working changes, staged changes, and differences between commits. The important comparison was what this release would change relative to production.

Preserving that work was part of the agent's operating boundary, not an optional cleanup after the writing was done.

Read and use the rendered site

We built the site, inspected routes and metadata, and reviewed representative desktop and mobile layouts. The Next.js production checklist distinguishes a build from running in a production-like environment.

Neither check tells you whether the offer makes sense. You still have to read it.

A mobile comparison page made that concrete: long raw source URLs caused overflow. Descriptive link labels fixed the presentation while preserving the destinations. The build hadn't objected to the uglier version.

Interaction checks covered navigation, both pricing selections, contact-form branches and conditional fields, and the article grader's analysis and reset behavior.

We didn't submit contact or application messages, so delivery wasn't retested. Rendering and exercising form branches established something narrower.

Source review also found an older internal product brief disagreeing with the approved public offer configuration. We preserved the public terms and aligned the internal guidance during the subsequent system work.

Letting the agent pick whichever offer made the sentence easiest to write would have been a business decision disguised as editing.

Check the destination separately

After authorization to ship, the release record connected the final commit to a successful production deployment. The integration reported status through GitHub.

GitHub's deployment model associates deployment records with source refs and lets external services report status. It doesn't visit the website for us.

The saved public report contains 83 checks:

• 77 generated HTML routes.
• Three supporting resources expected to load.
• Three selected paths expected to return 404.

The report records no failures. Additional selected assertions checked the hero, diagram, centering markup, and default Context OS pricing selection.

That's 83 checks, not 83 rewritten pages. It also isn't an exhaustive confidentiality audit or a fresh factual review of every old article.

The useful result is more specific: the approved change reached the public site, and the inspected responses matched the release expectations.

Then we improved the system—and found another miss

The website shipped first. The Context OS upgrade and article batch followed. The new validator and enrichment workflow didn't retroactively produce the rewrite.

We used the work to identify places that still depended on repeated explanation or someone remembering a check.

Make the destination part of the writing workflow

Our site consumes Markdown with supported metadata and author information. Refreshes need their original publication dates. New drafts need to stay outside the published-content input.

Those are specific requirements. Generic CMS instructions weren't enough.

We added clearer task routing and a complete article cycle: research, outline, draft, separate enrichment, editorial review, and staging before moving to the next article.

Enrichment was supposed to answer unresolved reader questions and strengthen weak claims. It wasn't supposed to mean “add more words,” especially after a website project about removing them.

Runnable checks covered expected files, metadata, structure, links, and whether receipts still matched the article and research. Refresh checks preserved identity and required embedded features. The focused tool suite passed 21 tests, none skipped.

Those tests could establish their mechanical checks. They couldn't establish that an article sounded like us.

Google's helpful-content questions include sourcing, accuracy, and whether the reader can achieve their goal. Counting links doesn't answer those questions either.

A clean validation result can coexist with a bad editorial decision

The first ownership-guide pilot completed research, drafting, enrichment, source review, validation, and a local rendered review. Its readiness check returned zero errors and warnings.

The release plan kept it a draft until publication was authorized. Local desktop and mobile review found no page-level overflow. That preview excluded the actual site's custom components and automatic CTAs, which still needed release checks.

Those were useful results. They were not evidence that every later article would be good.

The subsequent batch made the limitation obvious. All ten articles landed in the same three-H2, nine-H3 structure. Nine had no bullet lists. Paragraphs were consistently heavier than several of the older pieces.

The factual qualifications and operating detail were often useful individually. Together, they pushed the voice toward an instruction manual. The editorial pass accepted too much uniformity because the mechanical requirements were satisfied.

That's a process failure worth keeping, particularly in an article about using our own process.

The correction is to compare the work with approved articles during editorial review: argument, section shape, paragraph rhythm, examples, and how much machinery the reader actually needs. The style guide doesn't need rewriting to excuse the mismatch.

This account is part of that local revision pass. Its effect on future batches still needs to be demonstrated.

Keep the failure as a test case

Anthropic's evaluation guidance recommends turning real failures into cases. The same idea applies to both technical and editorial work, though they need different kinds of assessment.

Another review in the batch exposed a research problem: asking only what supports a proposed claim encourages confirmation-seeking. We changed the instructions to ask neutral questions and retain contradicting evidence.

A supported refutation now counts as completed research. That's an implemented instruction change; its effect on future work remains something to observe.

The website outcome is concrete: new copy and hierarchy, preserved design, an identified production release, and public checks. The system outcome is a set of changes we can inspect and keep testing.

Neither requires an invented revenue chart.

The next useful evidence is where a correction repeats, a stale input survives, or a supposedly passed review misses the point. That's how operational documents become systems, and how a Context OS earns more than the impressive-folder label.

If you have a recurring job stuck between a draft and something usable, bring it to a scoping call. We can start with the work and the decisions it requires. We should also be able to tell you where our own process needed another pass.