We don't run every engagement through the same checklist. An advisory engagement looks nothing like a six-week Build. What stays consistent is the way we think about the work.
Working principles
We start with the real work
Most "automation" engagements that fail do so because the team automated a process that shouldn't have existed. We start by mapping how work actually moves through your team - what gets decided where, where handoffs get dropped, which steps people have built workarounds for - before any tool decision.
We shape by prototyping
Sketches, workflow maps, lightweight prototypes. We make ideas concrete cheaply, before anything large gets committed. A working sketch in week one is worth more than a perfect plan in week four.
We harden what proves useful
Once something shows value, we make it reliable: structure, integrations, permissions, evals for models, prompts, and agents, documentation, monitoring, ownership. This is the part that determines whether the system survives contact with the real world - and the part most teams underestimate.
We hand over clearly
The aim is a system your team understands and can run. Handover is the actual deliverable; we shouldn't be in the loop after we leave. We document, we train, and we leave you more capable than we found you.
Different work needs different rhythm
The shape of the engagement depends on what you actually need.
Practical Technology Advice engagements usually mean one or two focused workshops plus a follow-up memo. The deliverable is judgment - a build-vs-buy recommendation, a vendor review, a roadmap, a decision someone in leadership has been postponing because they didn't have the right person to talk to. There's no build phase. The output is a document you can act on.
AI Opportunity Sprint engagements typically run one to two weeks. We move between interviews, workflow mapping, prompt tests, prototype sketches, and pilot planning - in whichever order the situation needs. The output is an AI opportunity map and a scoped first pilot, with the "do not start with this" calls explained. Operational implementation is explicitly out of scope; that's a separate engagement.
AI Operations Build engagements vary most. The smallest are a few weeks of focused work - taking a single workflow or prototype to production-grade. Larger ones involve integration with existing systems, model, prompt, and agent evals, observability work, and the handover step that makes the system durable. We'd rather scope tightly and ship one useful thing reliably than promise five and deliver none.
If you're not sure which fits, the easiest first step is a 25-minute conversation. We'll tell you honestly - including whether you need any of our engagements at all.
What you can expect
- Direct contact. You work with the two of us. No middlemen, no escalation chains.
- Local team, direct collaboration. Based in Copenhagen, working with clients across Denmark and beyond. Many sessions run remote; we travel when being in the same room moves the work forward.
- No 40-page strategy decks. Outputs are tight, useful, and written for the people who will act on them.
- Honest scoping. If the right answer is to simplify, to not build, or to use a tool you already own, that's the answer you'll get.
- Real handover. Every Build engagement ends with documentation your team can follow and confirmation that they can maintain what we built without us.
Tools we use
We work with what fits the problem, not a fixed stack:
- LLM providers - Anthropic Claude, OpenAI, Google Gemini, and open-source models when they fit. We use evals to compare model+prompt cost, reliability, latency, and quality for the workflow. Deployment can be direct use of the chosen provider, your existing platform, or a routing layer when that genuinely adds value.
- Agent harnesses & frameworks - test harnesses, tool-calling loops, retrieval, memory, and agentic frameworks such as LangGraph, OpenAI Agents SDK, Vercel AI SDK, or custom orchestration. The point is not extra ceremony; it is making agents inspectable, testable, and safe to run.
- Workflow & automation - tools you already use, tools we recommend for practical value, or custom integrations. We help connect your systems to AI agents and workflows using MCP (Model Context Protocol) or other integrations, depending on the case.
- Data & integration - we make sure the system has the data it needs, in the format and cadence the workflow requires: API integrations, data cleanup, operational datasets, reporting handoffs, and heavier processing in Python, Spark, or Databricks when the case calls for it. The point is trustworthy inputs and outputs, not a bigger data platform by default.
- The boring-but-essential layer - model, prompt, and agent evals, observability, error handling, auth and permissions, monitoring, documentation. Most of what makes an AI system survive in production.
We connect to your existing CRM, ERP, and communication tools rather than replacing them.
Common questions
Do you travel to client sites? Yes, when it adds value. Many sessions work well remotely, but we travel for discovery, workshops, kickoff, handover, or situations where being in the same room will unblock decisions faster.
Do we need a technical team on our side? No. We bring the technical depth. We need someone on your side who understands your processes and can make decisions about how work should flow. That person doesn't need to be technical.
How long does a typical engagement take? It depends on the engagement type. An advisory engagement is usually one or two workshops plus a memo. An AI Opportunity Sprint can take one to two weeks. An AI Operations Build varies - usually a few weeks for one focused workflow, longer for bigger scopes. We agree the shape before we start so you know what you'll get and when.
What if our processes aren't documented? That's the norm, not the exception. Undocumented processes are exactly what the early stages of any engagement are designed to surface. We're used to working from conversations and observation, not existing documentation.
What if we already have a prototype? Bring it in. The AI Operations Build service is set up to take prototypes (Lovable, Cursor, n8n, an LLM API, a notebook, an agent that almost-works) from working-in-demo to running-in-production. You don't need to start with a Sprint.
Can you work with our existing tools and vendors? Yes. We usually start with what you already have: CRM, ERP, Microsoft 365, data platforms, identity, support tools, and approved AI providers. If something else would create more practical value, we explain the tradeoff before recommending it.
Who owns the solution afterwards? You do. We design for handover from the start: documentation, access, tests, monitoring, and enough context for your team or vendor to operate the system without us in the loop.
Which model or platform should we choose? That depends on the workflow. We compare options against the task, cost, latency, reliability, data constraints, and operating model, then recommend the simplest setup that can do the job well.