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

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.

The Artefacts Around a Reliable Workflow

A serious AI workflow is not one giant skill. It is a set of artefacts with different owners and failure modes.

1. Connected evidence

Approved connectors land organisation-scoped evidence inside the selected deployment boundary. Connector scope, permissions, and freshness are explicit.

2. A published Twin product

The product contract records the reviewed source mappings, grain, fields, joins, freshness expectations, and validation rules. Publication creates a stable governed relation and version.

3. Ambient business context

Stable organisational facts, such as terminology, reporting conventions, and operating constraints, can be supplied as scoped context. This keeps durable business knowledge out of a task-specific skill.

4. A narrow task skill

The skill describes the procedure: select the approved product, apply the relevant filters, produce a particular output, and escalate unsupported requests.

5. Deterministic tool guardrails

The tool layer enforces what prose cannot. In the governed Twin path, the agent supplies a typed selection rather than arbitrary SQL. The runtime validates fields and filters, injects organisation scope, and mechanically compiles a read-only query against the exact activated relation.

6. Validation and evaluation

Validation is part of publishing the product. Where a workflow warrants it, a product-specific evaluation suite can test whether the agent chooses and uses the product correctly. Evaluations remain separate from the skill so the instructions do not grade themselves.

7. Human authority

Humans approve business definitions and retain the sign-off points that matter. An agent can prepare a close commentary or identify a variance; it should not silently turn a proposed definition or draft action into approved company state.

This separation makes change review meaningful. A new margin definition is a product-contract change. A different narrative format is a task-skill change. A stricter row limit is a tool-policy change. Each can be inspected and tested at the layer that actually 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;
• put that proposal through human review before publication;
• 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.

---

Previous: Why Your Operational Reporting Is Lying to You. See how the Twin turns fragmented finance, pipeline, and delivery evidence into an approved cross-functional product.

Related: LLM-Agnostic by Design. See why model choice can change while the governed business product and its evaluation evidence remain stable.