How Swfte builds with Cortex / Engineering workflow
Building features with Cortex, Claude Code and the Nexus harness
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.
Cortex does not front Swfte's own website work today. We build it with Claude Code, a rules file, build checks, parallel agents and completion gates, and Nexus captures what our coding agents do. Cortex can hand a coding task to Claude Code or Codex through Nexus, and that capability is built. This page keeps the two apart and labels every practice.
What we actually do today
Our website is built with Claude Code, the command-line coding agent. The commits we can see carry a Claude co-author line, and the repository holds a rules file that tells the agent how to behave in it. Alongside the agent we use scripts that check the work, several agents running in parallel, and written completion gates. Nexus, our governance layer for coding agents, captures what the agents do on our own machines.
Cortex is not in that list. Cortex has shipped code for handing a coding task to Claude Code or Codex through Nexus, but we found no use of it on our website repository. We say so here because the rest of this page describes what Cortex does, and a reader should not assume that it is also how we ship our own site. It is not, yet.
A note on names, because Nexus is used for more than one thing. On this page Nexus means the layer that wraps a coding agent on a machine, captures what it does and applies allow, deny or ask rules. It is separate from the Nexus harness, a desktop and daemon runtime built above it, and from the Nexus governance products for AI agents and SaaS tools. Where the practices below say Nexus, they mean the first of the three.
The five practices we can point to
Each of these is in use at Swfte, in our own repositories or on our own machines.
A rules file the agent must follow
The repository has a plain-language rules file that states what the agent may and may not change. One rule, for example, says a shipped localised page address keeps its translation forever. The file is the place where a decision is written down once, so that every new session starts with it.
Build checks that enforce the rules
A script runs before every build and fails it when a rule is broken. The slug lockfile is the clearest case: translations are append-only, and the build stops if a page is missing from the lockfile. A rule that nothing checks is advice. A rule that fails the build is a control.
Parallel agents in separate worktrees
Several agents work at the same time, each in its own git worktree, so one agent's half-finished change cannot overwrite another's. The results are brought together by a person or by a parent agent that re-checks them. We describe this qualitatively only, and we publish no speed figures.
Completion gates
Before a large task starts we write the gates that will show it is done, with the check to run and the result expected. A gate that is ticked without recorded evidence counts as unmet. Most gates in our website ledgers are manual evidence rather than runnable commands, and the page on automated review says so.
Nexus capture on our machines
We run our coding agents through Nexus capture, which records what the agent did as events on the machine. That is all we claim. It is machine-local, so it is not something a reader can inspect in a repository, and we do not describe it as more than a record.
How Cortex hands a coding task to a coding agent
This is the built path in the product. It is not how we build our own site today.
- 01
Grant a folder
You give Cortex a folder where coding work is allowed. The grant is checked against the real path on disk, so a shortcut or a relative path cannot carry the agent outside the folder you chose. Nothing outside the grant is available to the task.
- 02
Choose a mode
There are three modes. Plan mode is read-only: the agent can look and propose. Edit mode lets the agent change files. Run mode adds shell commands. Start in plan mode, read what it proposes, and move up only when the plan is right.
- 03
Hand the task to Claude Code or Codex
From a chat, an assistant starts the task with the coding agent through Nexus, headless, in the granted folder. Cortex shows streamed progress and a task status you can ask about, and you can cancel the run. Nexus sits between the agent and the machine.
- 04
Answer approval cards
When the agent attempts a call that needs a decision, Nexus holds it and an approval card appears in the chat. You allow it, refuse it, or let it expire, and an expired card does not approve the call. Each card says what the agent wants to do, so you can decide on the facts and not on a hunch.
- 05
Verify and review
When the run finishes, ask for verification, gate results and the audit trail. Cortex has chat tools for each. Then read the diff yourself. A completed run is a proposal about your code, and it reaches the codebase only through your normal review and release.
What is allowed without asking, and what is not
In coding sessions run inside Cortex, only three tools are allowed without asking: Read, Glob and Grep, which look at files and search them. Everything else asks. The prompt is answered by a person, and if nobody answers within a short time it is treated as a refusal. High-risk actions are held to a stricter rule: sending, paying, deleting, pushing and running shell commands always need a person, even when auto-approve is on.
Two cautions apply. First, if Nexus is not installed, Cortex falls back to running the coding agent without governance. So check that it is on before you trust a run, and do not assume it from the interface. Second, a developer setting exists that switches the prompts off. It is not the default, and it should never be on for shared or production work. Governance you can silently bypass is not governance.
The Studio MCP server and the triage command
Studio has an MCP server that lets a coding agent build, verify, run and deploy things on the platform: workflows, agents, widgets and more. Deployment is gated twice. The call must carry an explicit confirmation, and an environment flag must allow deployment at all. Without both, the deploy tool refuses. That is a built control. We do not claim that our own agents use it for our site.
The swfte triage command is a smaller tool. Given an issue, it asks a triage agent for a diagnosis and returns structured JSON: a likely root cause, the component affected, a confidence level and suggested fix text. It does not open pull requests and it does not change code. The loop it points to, where an agent reads the diagnosis and a person approves the fix, is design intent. We have no record of our coding agents being driven through it.
A worked example, labelled design intent
Here is how we would run a small feature through Cortex. It is design intent, not a description of something we have done. A developer asks an assistant in Cortex to add a field to a settings form. The assistant hands the task to Claude Code in plan mode, in the one granted folder. The agent reads the code and proposes the change. The developer reads the plan and corrects one assumption.
The developer then moves the task to edit mode. A request to run the project's tests arrives as an approval card, and the developer allows it. The agent proposes pushing to the remote, which is a high-risk action, and the developer refuses: the change goes through normal review first. Gates run, a colleague reviews the diff, and a person merges. If we have a real run of our own to show, it will replace this one: <real internal example - founder to fill>.
Limits, and what stays with a person
The limits are real. The Nexus harness is an implemented runtime whose release acceptance is incomplete. The operating system sandbox has been proven on macOS only. The tests around Cortex's Nexus path are thin. The collector that Nexus uses documents a control interface without authentication of its own, which Cortex mitigates on its side. So treat the governed path as one layer of protection and keep your normal review and release gates behind it.
A person chooses the folder, the mode and the task. A person answers every approval card that matters, and a person reads the diff. A person merges and a person releases. Nothing on this page lets an agent merge its own work or deploy without confirmation. We make no claim about how much faster any of this makes anyone, because we have not measured it.
Engineering workflow: what is in use, built and designed
The first five rows describe how Swfte builds today. Cortex is not part of them.
| Practice | Status | What we can point to |
|---|---|---|
| Claude Code builds the website | In use at Swfte | The commits we can see carry a Claude co-author line, and the repository holds a rules file for the agent. We publish no speed figures. |
| A rules file enforced by a prebuild guard such as the slug lockfile | In use at Swfte | Translations are append-only, and the build fails if a page is missing from the lockfile. |
| Parallel agents in separate git worktrees | In use at Swfte | Real. Described qualitatively only. |
| Completion gates written before large tasks | In use at Swfte | Gate ledgers exist for our website work. Most entries are manual evidence rather than runnable commands. |
| Nexus capture of coding-agent actions on our machines | In use at Swfte | Machine-local, so we cannot point to it in a repository. We claim a record of agent actions and no more. |
| Cortex hands a coding task to Claude Code or Codex through Nexus, with approval cards | Built in the product | Folder grants, plan, edit and run modes, and in-chat approval cards exist. We found no use of it on our own website work. |
| The Studio MCP server with build, verify, run and deploy tools | Built in the product | Deploy needs an explicit confirmation and an environment flag. |
| The swfte triage command | Built in the product | Returns a JSON diagnosis with suggested fix text. It does not open pull requests. |
| Cortex fronting Swfte's own website and product work | Designed for | Not done. This is how you can do it, and it is a plan for us. |
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.
Frequently asked questions
Does Swfte run this on its own company information?
Partly. We build our website with Claude Code, a rules file, build checks, parallel agents and completion gates, and Nexus captures agent actions on our machines. We do not run our own development through Cortex today. Handing coding work from Cortex to Claude Code or Codex is built in the product and is a plan for us.
Can Cortex hand a coding task to Claude Code or Codex?
Yes. Through Nexus, an assistant in Cortex can start a coding task in a folder you have granted, in plan, edit or run mode. Calls that need a decision appear as approval cards in the chat. The path is built, and its test coverage is thin, so keep your own review and release gates behind it.
What happens if Nexus is not installed?
Cortex falls back to running the coding agent without governance. Check that Nexus is installed and active before you rely on approval cards or the audit trail. Treat an ungoverned run as untrusted work and review it as you would any outside contribution.
Which actions does the agent take without asking?
In Cortex coding sessions only Read, Glob and Grep run without asking. Everything else prompts, and a prompt that nobody answers is refused. Sending, paying, deleting, pushing and shell commands always need a person, even with auto-approve on. A developer setting can switch prompts off. It is not the default.
Can the agent deploy to production by itself?
No. The Studio MCP server's deploy tool needs an explicit confirmation on the call and an environment flag that allows deployment. Without both it refuses. That governs the tool. Your own release process, with review and gates, should still decide what reaches production.
Does swfte triage fix the bug?
No. It asks a triage agent for a diagnosis and returns JSON with a likely root cause, the affected component, a confidence level and suggested fix text. It does not open pull requests or edit code. A person or a coding agent still has to do the work, and a person approves it.
How much faster does this make engineering?
We do not know, and we publish no figures. We have not measured speed or savings, and we will not guess. What we can say is qualitative: we run several agents in parallel in separate worktrees and write completion gates before large tasks. Measure it in your own team before you plan around any number.
Take engineering workflow further with Swfte
Start with one entry point. Add intelligence, agents, workflows and infrastructure as you prove value.