agnostisk. dk

Agnostisk is my way of talking about technical freedom of movement. Database-agnostic. Tool-agnostic. Model-agnostic. If the analogy is allowed to travel a bit further: agnostisk.liv.

The blinking endings are the point. You can use a technology very intensely without wanting to marry it. The talk is about what that looks like in practice when the stack includes Claude Code, Codex, local models on DGX Spark, and a toolkit layer that is meant to survive changes in vendors and interfaces.

This is not an anti-Claude talk. Quite the opposite. It is a talk about why Claude becomes more useful when it is part of a setup with real optionality around it.

Claude Code CPH

The idea

What I mean by “agnostic” in AI

I do not mean neutral. I mean hard to trap.

In AI the word already has a practical meaning: vendor-agnostic, model-agnostic, interface-agnostic. Not because every tool is equal, but because the useful thing is keeping the option to move when the tradeoff changes.

Vendor-agnostic

Anthropic today, something else tomorrow if needed.

Model-agnostic

Claude for one task, Qwen or GPT for another.

Tool-agnostic

The workflow matters more than the logo in the corner.

Claude Code CPH

The setup

How I have built around that idea

The model is only one layer. The useful layer is the harness.

Interfaces

Claude Code here. Codex when that shape is better. Local model access on DGX Spark when privacy, speed, or experimentation point that way.

Portable layer

`fhh-toolkit` holds the reusable part: plugins, writing rules, engineering rules, coordinator flows, and shared ways of working. Fos consumes that layer instead of inventing it again.

Project layer

Fos keeps the project-specific parts: graph logic, product hooks, deployment details, and the things that should stay tied to the actual system.

Claude Code CPH

Routing

What becomes possible once roles matter more than vendors

In fos I have drifted toward routing by logical role rather than by provider name.

`planner.deep`

For decomposition, comparison, synthesis, and sharper decisions.

`coder.fast`

For mechanical edits, short loops, patches, and fast tool use.

`private.local`

For work that should stay on Spark and not leave the machine.

`fallback.general`

For keeping the work moving when the preferred backend is down or wrong.

The useful consequence is simple: changing backend should not require changing the whole mental model. That is a more stable contract than “we are a Claude shop” or “we are a local-model shop”.

Claude Code CPH

Why this talk

Why I think this belongs at the meetup

Because the interesting question is no longer whether Claude is good. It obviously is.

The more interesting question is what a serious workflow looks like once you stop treating one model as the whole story. I use Claude a lot. The “polyamorous relationship” line is a joke, but only half a joke. The real subject is how to keep leverage, flexibility, and local extensibility without losing the convenience of great hosted tools.

Audience value

A sharper model for tools, routing, and lock-in.

Format

15 minutes. Practical architecture. No evangelism.

Angle

Builder’s view. Not a brand deck. Not a manifesto.