Human Skills for Agentic AI

I see different people and businesses get very different return on investment with AI. When I double click with the people/peers/business leaders, the cause is rarely the LLM, which usually performs well. The cause is the question it was given, or the goal it was set.

Two human skills decide how much value we extract from large language models: asking the right question, and structuring our thinking. Neither is new. Both sit underneath first-principles reasoning, critical thinking and the patient work of organising ideas into a logical whole. Both are also hard to cultivate.

Why these skills are hard

We are primates wired for action, and reflex usually beats reflection. Organisations then reward a bias for action, which strengthens the reflex further.

Every serious discipline has built a counterweight. Engineers design before they write code. Product teams start from the customer outcome and work backwards. Strategy comes before operations. These practices exist because they are not intuitive. If they came naturally, nobody would need to write them down.

There is a second reflex at work: we reason by analogy. We copy what worked elsewhere, what the competitor launched, or what the last project did. Analogy is fast and usually good enough, which is why it is dangerous. First-principles thinking is slower. It strips a problem down to the facts that cannot be reduced further and rebuilds from there. Most teams skip this step, and the model, which is very good at analogy, happily skips it with them.

Much of the poor-quality AI output I see across customers, peers and teams is not really a model problem. It is a thinking problem that happens to come out of a model.

Example

Take an affordable housing loan. The LLM model stays the same throughout, at least among frontier models, and only the question changes.

The first question is about the task

How does credit decisioning work for an affordable housing loan? The answer is competent. It covers borrower profile, bureau score, income stability and loan-to-value, ending in approve or decline. The problem reads as a yes-or-no classification. That answer is correct, but it is incomplete.

To get past the task, strip lending to first principles. A lender borrows money at one price and lends it at a higher price. Profit is that spread, minus credit losses and the cost of operating, earned over the life of the loan. Every element of a lending business exists to protect or widen that spread. Once you see this, the next question asks itself.

The second question is about the goal

How does a lender make money on affordable housing loans? Now the frame shifts. Lending becomes an optimisation problem. The lender has to deploy available capital to the right borrowers, at acceptable risk and as quickly as possible, without breaking risk policy or regulation.

In this frame, every rejection has a cost: lost revenue, idle capital, and a family that does not get a home. Every approval carries the risk of losing the principal. Each default raises the cost of funds, which puts pressure back on the business. The decision is no longer a gate. It is a trade-off that has to be managed.

The third question is about structure

What end-to-end system delivers that goal? The answer becomes a loop:

• Policy defines whom we lend to and on what terms.
• Sourcing brings in leads that fit the policy.
• Underwriting and origination enforce the policy at the point of decision.
• Monitoring reads early signals from repayment behaviour. Those signals feed back to tune the policy.

The credit decision turns out to be one step in a continuous system. The model knew all three answers from the start. It only revealed the deeper ones because the questions changed.

Part one: in chat, a weak question costs you insight

Without these skills, a leadership team asks the task question and gets a well-formatted note on scorecards. The team then spends a quarter improving approval accuracy by two points while slow turnaround quietly erodes conversion. Nobody notices, because nobody asked about turnaround.

With these skills, the same conversation surfaces the real tensions: approval rate against default rate, time to disburse against depth of verification, and growth against cost of funds. The discussion moves from whether the model is accurate to what the business should optimise.

In chat, the damage from a weak question is limited. A person reads the answer and can still apply judgement.

Part two: in agents, a wrong goal costs you the business

An agent does not just answer. It acts. If you give it a wrong goal, it will pursue that goal with tireless diligence and no sense of irony.

In the first scenario, the agent's goal is to minimise defaults. It succeeds by approving almost nobody. The default rate looks excellent, the loan book shrinks, and the sales team spends its days rescheduling meetings. The dashboard is green while the business is in the red.

In the second scenario, the goal is to maximise approvals. Growth looks spectacular for three quarters, and the collections team arrives in the fourth.

In the third scenario, the goal is to optimise risk-adjusted return on deployed capital, within risk policy, with turnaround time as a constraint. The agent design follows the structure of the lending loop:

• One component checks the application against policy.
• One verifies documents.
• One produces an underwriting recommendation with its reasoning.
• One watches repayment signals after disbursement.
• Humans decide when the policy itself should change.

Each component has its own measure, and every measure rolls up to the goal.

The model is the same in all three scenarios. The outcomes differ entirely, and the only variable is the quality of human thinking before the first line of configuration. In chat, a wrong question wastes an afternoon. In an agent, a wrong goal compounds at machine speed.

Why I am writing about this now

For most of its history, enterprise technology sat one step removed from the business. Teams built applications that mapped a process, or analytics that informed a decision, but rarely owned an end-to-end business loop. Agentic AI changes this. Technology teams now build agents that make decisions and take actions the way business users do. This is operations territory, where decisions have a direct and material impact on the business. Building an agent that decides on its own requires the same two skills this piece began with: asking the right question and structuring our thinking. They are what unlock the real value of this technology.

What I do and it works for me

Before I ask an LLM model a question or design an agent, I ask myself four questions:

1. What is the task?
2. What is fundamentally true about this problem?
3. What is the goal behind the task?
4. What structure delivers that goal?

I spend real time on these questions. I probe, structure and iterate. The model already knows the answers. What matters is whether I know what to ask.

What is your recipe?

I use LLM to organise my thoughts - the ideas are mine but this is an AI assisted post.