# Skills, Not Prompts: How Forward-Deployed Engineers Codify Finance Processes

> A skill can make an agent operationally useful, but it should never become a hidden source of business truth. MLX separates procedure from the governed meaning in your Twin.

Published: 2025-11-22
Updated: 2026-09-10
Author: Archie Norman (Founder, MLX)
Category: Twin
Tags: twin, skills, forward-deployed-engineering, finance-ops, governed-ai
Canonical URL: https://mlx.systems/blog/skills-not-prompts

## TL;DR

- A prompt can guide a conversation, but it is not an adequate control surface for a recurring finance or operations workflow.
- The Twin owns approved business meaning; a skill supplies narrow operational guidance about how to perform a task with that meaning.
- Repeatability comes from the whole system (published product contracts, typed tools, policy checks, validation, optional evaluations, and human approval), not from a skill claiming to be deterministic.

---

The fastest way to make an AI demo look impressive is to write a long prompt. The fastest way to make an AI deployment become ungovernable is to let that prompt carry the entire operating model of the business.

A finance team does not just need an agent that knows what to say. It needs approved definitions, constrained access, reviewable procedures, evidence, and clear points where a human remains responsible.

That is why MLX uses skills, but also why we are precise about what a skill is allowed to own.

## Why Prompts Are a Weak Operating Model

Prompting is useful for exploration. It is weak as the sole delivery mechanism for a recurring business process:

1. **Business meaning becomes implicit.** A line such as “calculate customer margin” hides choices about revenue recognition, labour cost, account mapping, and time period.
2. **Instructions drift.** Teams copy, edit, and extend prompts until several incompatible versions of the process exist.
3. **The control boundary is unclear.** Natural-language instructions can ask a model to behave, but they cannot enforce row scope, allowed fields, read-only access, or approval policy.
4. **Success is hard to test.** A fluent answer can look right even when it used the wrong source, stale data, or an unsupported definition.

Putting the prompt in version control helps with review, but it does not solve those deeper issues. A versioned ambiguity is still an ambiguity.

## What a Skill Is, and Is Not

In MLX, a skill is narrow operational context for a bounded task. It can tell an agent:

- which approved business product or source is relevant;
- which tool to use and in what sequence;
- which inputs are required;
- how the expected output should be structured;
- when evidence is insufficient;
- when to stop, escalate, or ask for human review.

For example, a working-capital review skill might tell the agent to use the approved receivables product, compare overdue balances with the prior period, group material movements by customer segment, and escalate any requested field that the contract does not expose.

The skill should **not** decide what “overdue,” “active customer,” or “material movement” means. Those definitions belong in the approved Twin product, where they can be reviewed, published, versioned, validated, and shared across every workflow that uses them.

This boundary is deliberate:

> The Twin governs what the business data means. A task skill guides how the agent works with that approved meaning.

Publication also generates a product policy skill that binds governed access to the approved product and declares its machine query policy. That system-generated policy is different from a reusable task skill: the runtime tool enforces the declared contract rather than relying on the model to obey it.

## Put Each Rule Where It Can Be Enforced

| Concern | Where it belongs |
| --- | --- |
| Which records count and how a measure is calculated | The published Twin definition |
| How to sequence a review or format commentary | The task skill |
| Which fields, tools and operations are permitted | Deterministic tool and access policy |
| Whether the workflow succeeds on known cases | A separate evaluation suite |
| Whether a consequential output is accepted | The responsible business owner's review |

A new margin definition is a contract change. A different narrative format is a skill change. A stricter row limit is a tool-policy change. This separation lets the team review the decision at the layer that owns it.

## Where Forward-Deployed Engineering Helps

The hard part is rarely writing Markdown. It is discovering how the organisation really works and assigning each piece of knowledge to the correct control surface.

A forward-deployed engineer works with finance and operations owners to:

- identify the source systems and permissions required for the use case;
- map ambiguous identifiers and definitions into a proposed Twin product;
- resolve the business decisions and apply the required review policy;
- capture stable organisational context without bloating every task instruction;
- author the narrow operational skill around the approved product;
- add deterministic constraints in the tool or policy layer;
- define evaluation cases for risks that need ongoing measurement;
- preserve explicit review and approval steps.

The key judgment is often what **not** to put in the skill.

If a rule must be true for every consumer, it probably belongs in the product contract or policy layer. If it describes how one workflow presents or sequences work, it may belong in a task skill. If it decides whether an answer is acceptable, it belongs in validation or an evaluation contract.

## A Worked Example: Period-End Variance Review

Consider a period-end variance workflow. The implementation could be separated like this:

- **Twin product:** the approved actual-versus-budget relation, entity and period grain, account hierarchy, currency treatment, materiality fields, freshness expectation, and validation evidence.
- **Task skill:** query the activated product for the selected period, rank material movements, distinguish supported explanations from missing evidence, and draft commentary in the team's format.
- **Tool policy:** permit only fields and filters in the product contract, enforce organisation scope, cap result size, and keep the query read-only.
- **Evaluation suite, where defined:** test known periods and questions to confirm that the agent selects the right product, cites its version and freshness, and refuses unsupported analysis.
- **Human review:** the controller reviews the commentary and remains responsible for the signed-off close narrative.

The model may still phrase two drafts differently. What matters is that both drafts are constrained to the same approved product, permissions, and evidence, and that neither can quietly redefine the metric.

## Own the Process at the Right Layers

Customer control does not mean handing a finance team an empty prompt box. It means making the important artefacts visible and governable:

- product definitions can be reviewed and versioned;
- skills can be inspected and changed;
- tool permissions can be enforced;
- evaluations can reveal regressions;
- model routes can change without changing the business contract;
- human approval remains explicit.

Skills are part of that system. They are valuable because they turn tacit procedure into reviewable operational guidance. They become dangerous only when they are asked to carry meaning or controls that belong somewhere else.

The aim is not “the same wording every time.” It is the same approved business contract, the same enforced boundaries, and a clear record of what the agent used.