Decision Architecture for Salesforce and Agentforce

Your system is making decisions. Can you see them?

Before an agent goes live, someone has to decide what it may decide. In most companies nobody has, so the builder decides. I find those decisions, give each one an owner, and hold them in Salesforce where the agent cannot talk its way around them.

Take the 3-question test Work with me

Tested in my own org: 7 of 7 acceptance tests passed. 10 of 12 ways around the agent still worked.

Where this stands

It isn't proven yet. Nobody has proven the alternative either: most agent projects run on rules nobody decided.

Decision Architecture is a working theory and Tekin Method is a young practice. I am looking for the first five companies to test it with, in the open: free for them, done by hand, with a written result they keep. If it doesn't help, you'll know quickly and so will I.

Three ways in

Plug it into what you already run.

The test · free

Three questions. One sentence back.

Who says yes above the limit? Can someone approve their own request? What may the agent tell the customer? Your answers come back as one sentence about how your team actually decides.

Take it now →

Live in English, Dutch, German, French, Spanish and Turkish. Nothing is saved or sent.

The plugin · free

Hold the rule in Salesforce.

One rule per process, kept in metadata with a version. A check the agent has to pass before it acts. A record of every decision: who, when, under which rule. An instruction is not enforcement; this is.

Pilot. Version 0.1 installs in a clean org and passes its tests. The process-independent version is being built now.

The package · first five free

One process, every rule decided.

I take one process an agent will touch, find every rule nobody decided, get each one an owner, and hand you the boundary written down and testable: what the agent may do, where a person decides, and what it may never say.

Ask for one of the five →

Done by hand. After the first five, scope and price are agreed in writing before anything starts.

How it works

Decide first. Then build.

The work is semantic before it is technical: decide what the words mean, then build. Six steps, the same on every engagement.

Question the storyWho, what, when, how and why, until the answers hold. Every gap becomes a named decision with an owner.
Separate authority from capabilityWho the actor is, what they are allowed to do, and what the system lets them do.
Design the work before the toolEntry criteria, conditions, exceptions, calculations, impact, order of execution.
Choose the tool on evidenceFlow or Apex, compared openly against the team's capacity.
Make it durableCheckpoints, edge cases, a trace the organization can learn from, intervention points.
Ship in atomic unitsMetadata packages in a dependency-aware sequence.

Decision Architecture · working theory

Sort companies by the decisions they stand on, not by their industry.

Most of the ways we describe companies come from the assembly line: departments, cost centres, cost accounting, the income statement, even industry sectors. They describe transactions.

A company's vision implies a value function, and that function shapes the nature of its core decisions. So companies are more predictable than they look: once you know a decision's components, you can produce a lot of good action from it. A company's value sits less in its transactions than in its ability to keep producing good decisions, and that matters more as AI takes over the execution.

Same refund rule	Wins on lowest cost	Wins on experience
The decision is	a rule, applied the same way every time	a judgment about a relationship, inside a cap
Most dangerous pattern	exceptions that quietly become policy	one person becomes the queue
"A manager may make exceptions, no limit"	a leak	maybe the strategy, if it is capped and reviewed

Same industry, opposite decisions. Industry predicts neither row.

Work with me

Start small. Keep what works.

Free

The test

For anyone. Thirty seconds, one sentence about your process.

Free

Design partner

The plugin installed with you in a sandbox, on one process. We collect the evidence together: what it caught, what it missed.

Free · 3 to 5 companies

First five free

Authority Boundary Package

One process, every rule decided and owned, the boundary written and testable, ready for your team or your partner to build.

First five free · then agreed in writing

On request

Architect and advisor

Agentforce, Service Cloud and Data Cloud, mostly in regulated industries. For a long-term role or a defined advisory scope.

Let's talk

My story

I kept seeing the same failure.

I have spent more than eight years delivering Salesforce, mostly in regulated industries: four and a half years as an architect at EPAM Systems (PolSource), four years at Intech Consulting, and four years in SAP CRM consulting before that. I hold 12 Salesforce certifications.

Projects rarely failed in the build. They failed on rules nobody had decided, which ended up decided by whoever held the keyboard. With agents that gap got faster and quieter. In 2026 I went independent to work on that layer. I live in Istanbul and work remotely.

Contact

Tell me which process keeps you up at night.

If you want one of the five free packages, to be a design partner, or just to tell me where the test got it wrong, write to me on LinkedIn. I answer every message myself.

Message me on LinkedIn Take the test first