AI Workflows · Thinkery

Where it breaks.

It stays personal.

One person has worked out a genuinely good way to use AI for a task. It lives in their head, their prompts and their tabs. The team next to them solves the same problem differently every time, and nobody can tell which version is better.

Context gets rebuilt.

Every new session starts by reassembling what was already established: the repository, the decision made last quarter, the exception this customer has. That reconstruction is invisible in any plan, and it is often the largest single cost in the workflow.

Speed locally, drift across the team.

Coding agents make an individual noticeably faster while pulling the codebase in several directions at once. Review load rises, conventions diverge, and the time saved upstream reappears downstream as checking.

What changes with AI.

When AI enters a team, the tools change first and the way of working changes late — or not at all. Steps designed around a person doing them by hand stay in place, and the model gets fitted into a process that was never meant to include it.

So we start by mapping what actually happens: the tools, the people, the handoffs, the decision points, and the places where the same information is assembled more than once. That map is usually the first time anyone has seen the workflow whole.

Then we change the parts that remove real work. Not all of them — the ones that do.

AI-native engineering.

For engineering teams this gets specific. Coding agents work well on a task and badly on a codebase: they read what they are pointed at, and what they are pointed at is usually decided fresh every time by whoever is at the keyboard.

The work is in what surrounds the model. Which repository context is worth assembling once and reusing. How much of a previous session should survive into the next. Whether two agents running in parallel are cooperating or quietly duplicating each other. What review has to catch, and what should be caught before review.

We work at that level rather than at the level of which tool to buy. The tools change every few months; how a team coordinates work with them does not.

Reuse before rereading.

Efficiency here is not a separate goal. The repeated reads, the duplicate runs and the context assembled from scratch are the same problem seen from the resource side — and they cost time, tokens and attention at once.

So we look for what can be established once and reused: project context, decisions, the state of a task in flight. Where selection, reuse or measurement of context is a real part of the problem, LeanCTX can provide that layer.

Quality first. A workflow that uses fewer tokens and produces worse work has not improved.

What a project includes.

Understand

Workflow and handoff mapping
Where context is rebuilt
What AI actually changed so far

Build

Reusable project context
Agent handoffs and orchestration
Missing integrations between tools

Land it

Team practices, not just setup
Evaluation the team can run
Before-and-after measurement

Measure the change.

We decide what should improve before changing anything, because a workflow that feels faster and a workflow that is faster are different claims.

Depending on the work that can be task time, completion, output quality, rework after review, tokens, latency or cost. The task chooses the metric; we do not arrive with one.

Time · Completion · Quality · Rework · Tokens · Cost

Then we compare before and after on the workflow itself rather than on a demo.

Bring us the workflow.

Show us how the team works today and where you think AI should be making it better.

Start a conversation

hello@thinkery.ch