First-party story
How Swfte builds with Cortex
An honest account of how we build, review and approve work with Cortex, Claude Code and Nexus, and where the product goes further than we do.
We label every practice on these pages. Some we run on ourselves. Some the product can do today, and we make no claim that we use them. Some are how you can do it, which is design intent. Where we have a real example to show, we say so, and where we do not have one yet, we leave a visible gap rather than invent it.
Five parts of the story
Each page says what we can show, what the product can do, and what is design intent.
- Internal knowledge
How an organisation's own knowledge becomes an assistant that does one job, what Cortex does for that today, and what Swfte itself does and does not do yet.
- Engineering workflow
How Swfte builds software today, how Cortex can hand coding work to Claude Code or Codex under Nexus, and where a person has to say yes.
- Automated review
The difference between a step that finds problems and a step that approves a change, what Swfte runs today, and where our own review is still manual.
- Approvals and governance
The rule that an agent proposes and a person decides, how approvals work in Cortex, Nexus and workflows, which decisions Swfte keeps for its owner, and what is not built yet.
- Improvement loop
The five stages by which an organisation can improve what it runs with agents, what exists at each stage today, and which parts are still only a design.
Where we start: what is true today
Cortex is the Swfte AI workspace for the desktop. It holds knowledge bases, connects to tools over MCP, and can hand a coding task to Claude Code or Codex through the Nexus harness, with a person approving what needs approving. That is what the product does.
What we do ourselves is narrower, and we would rather say so here than let a headline suggest otherwise. Our website is built with Claude Code, under rules written down in the repository and enforced by scripts that run before every build. Our coding agents run with Nexus capture, so their actions are recorded. We write completion gates before large pieces of work, and we keep dated review documents. Cortex does not front that website work today, and we have not yet pointed Cortex at our own documents, code or tickets as a working knowledge base.
The rest of this section of the site is built on that distinction. For each part of the story, we say what we run, what the product can do, and what is design intent that you can use as a pattern.
The story in five parts
Each part has its own page, with a status label on every practice.
Internal knowledge into focused systems
How one job, one collection and one assistant beat an everything-index. What Cortex does with local and governed knowledge, and what we use today.
Read more about Internal knowledge into focused systemsCortex and dev tools to build features
Claude Code, MCP and the Nexus harness: how work is handed over, what is granted, and what asks first.
Read more about Cortex and dev tools to build featuresAutomated review steps
What finds problems, what approves the change, and why those are different jobs.
Read more about Automated review stepsApprovals and governance
What stays under human approval, how the approvals work, and what is not built yet.
Read more about Approvals and governanceThe improvement loop
Observe, propose, approve, ship, measure: what exists at each stage and what does not.
Read more about The improvement loopGoverned agents and compliance workflows
The pattern, with templates, for agents and workflows that carry identity, permissions, approvals and records.
Read more about Governed agents and compliance workflows
What stays with a person
Across all five parts, one rule holds. An agent proposes, and a person decides. People choose what is worth watching, approve or reject proposals that carry risk, and judge whether a change worked. Agents read, draft, analyse and prepare. Sending, paying, deleting, pushing and running shell commands are the actions that always need a person in Cortex, even when other prompts are switched off.
We also keep approvals that are not about code. Releasing a signed build, and keeping a live payment test rather than refunding it, are decisions our owner makes explicitly and records. Neither is delegated to an agent. That is the same pattern we describe for customers: name the decision, name who may take it, and keep the record.
Where a real example would help, and is not here yet
A first-party story is stronger with a concrete case: an internal question answered from our own knowledge base, a review that caught a real defect, an approval routed through Nexus, an improvement that shipped and what it changed. We have the machinery for each of those. We have not published a worked example of each. Until we do, the gap is marked: <real internal example - founder to fill>.
If you would like to see a live walkthrough of the product handling a case like yours, talk to our team. We would rather show you than describe it.
What is in use, what is built, and what is design intent
A summary across the five parts. Each deep page has its own table with more detail.
| Practice | Status | What we can point to |
|---|---|---|
| Claude Code builds our website | In use at Swfte | The repository carries the rules agents follow and the commit history shows the work. |
| Nexus capture of coding-agent actions | In use at Swfte | Our coding agents run through Nexus capture on our own machines, so their actions are recorded. |
| Rules enforced by scripts before every build | In use at Swfte | Translated URLs are append-only, and price and model data have to be re-checked by a date or the build fails. |
| Completion gates and dated review documents | In use at Swfte | We write acceptance gates before large pieces of work and keep numbered review findings with a closure record. |
| Cortex hands coding work to Claude Code or Codex through Nexus | Built in the product | Per-folder grants, plan, edit and run modes, and approval cards in the chat. We do not claim it fronts our own website work. |
| Knowledge bases and governed collections | Built in the product | On-device bases, and cloud collections with per-space roles. We do not claim we index our own internal knowledge in them today. |
| Cortex reading the company brain | Designed for | The client work exists but is not shipped, and the brain endpoints it needs are not finished. |
| A company-wide observe, propose, approve, ship, measure loop | Designed for | Pieces exist. The joined-up loop across code and operations is a design, not something we run. |
How to read the status
- In use at Swfte. We can point to it in our own repositories, pipelines or commit history.
- Built in the product. The product can do this today. We make no claim that we run it on ourselves.
- Designed for. How you can do it. Design intent, not a statement about what we have done.
The improvement loop
The loop is the shape of the whole story. The improvement-loop page says what exists at each stage.
- 01 · this page
Observe
Collect what is happening: errors, struggle signals, review findings, cost, support questions, usage.
People choose what is worth watching.
- 02 · this page
Propose
An agent turns an observation into a specific proposal: a diff, a workflow change, a policy edit.
The agent proposes. It does not apply.
- 03 · this page
Approve
A named person reviews the proposal and its evidence, and approves, edits or rejects it.
A person decides, and the decision is recorded.
- 04 · this page
Ship
The approved change goes out through the normal gates: tests, review, release.
The release gates still apply.
- 05 · this page
Measure
Compare the outcome with the reason you made the change, then feed it back into what you observe.
People judge whether it worked.
The last step feeds the first. What you measure becomes the next thing you observe.
Frequently asked questions
Does Swfte run this on its own company information?
Partly. We build our website with Claude Code under rules enforced by scripts, with Nexus capture and written completion gates. We have not yet run our own documents, code or tickets through Cortex as a working knowledge base, and Cortex does not front our website work today. The pages label each practice so you can tell which is which.
Is this a customer case study?
No. It is our own account of how we build, written to be checked against the product. It names no customers, quotes nobody and gives no speed or savings figures, because we do not have measured ones to publish.
What do the three status labels mean?
In use at Swfte means we can point to it in our own repositories, pipelines or history. Built in the product means the product can do it today and we make no claim that we run it on ourselves. Designed for means it is how you can do it, which is design intent.
What stays under human approval?
Anything that sends, pays, deletes, pushes or runs shell commands needs a person in Cortex. Releasing a signed build and similar owner decisions are made by people and recorded. Agents propose, read, draft and prepare, and a named person decides.
Can I use the same pattern in my organisation?
Yes, that is the purpose of the pages. Start with one job and one collection, put agents behind approval gates, and record decisions. The governed agents and compliance workflows pages give templates for the shape, and say which are designed rather than shipped.
Does this mean Swfte is compliant with a regulation?
No, and we do not claim that. Swfte provides technical controls, governance mechanisms and evidence that can support an organisation in meeting its own obligations. The exact posture depends on your use case, jurisdiction, deployment and configuration. This is not legal advice.
Build your own governed AI workspace
Start with one entry point. Add intelligence, agents, workflows and infrastructure as you prove value.