Anatomy of an Agent

CHAPTER 1The colleague that never sleeps, and the company that still needs you

The announcement that made the argument feel simple

On February 27, 2024, Klarna published an announcement about its new AI assistant. The payments company said that, in its first month, the assistant had handled 2.3 million conversations, representing two-thirds of its customer-service chats. It described the work as equivalent to that of 700 full-time agents. It also said the assistant operated around the clock in 23 markets and communicated in more than 35 languages. [C1-S1]

Read those numbers quickly and a straightforward story appears: the software arrived, the people became unnecessary, and a large business found a new operating model.

But that is not what the announcement established.

The figures were Klarna's reported outcomes. The comparison with 700 agents was a work-equivalence claim, not a list of 700 people dismissed because of the assistant. The projected $40 million profit improvement was an estimate for 2024, not an audited saving already achieved. The same announcement said customers could still choose to interact with live agents. [C1-S1]

Those qualifications do not make the deployment unimportant. They make the story useful.

A business had connected a model to a defined area of work. It had measured activity and reported results. It had kept a human route available. The system was neither a toy chatbot nor an artificial chief executive.

The next part of the story is equally instructive. In May 2025, reports about renewed human hiring were widely interpreted as an AI retreat. In a May 16 interview with Big Technology, Klarna's chief executive, Sebastian Siemiatkowski, disputed that interpretation. He said the assistant still handled roughly 1.3 million errands a month and that human hiring was intended to improve higher-end conversations previously outsourced. These remained claims from the company and its chief executive, reported in an interview. They did not independently settle every question about quality, cost or staffing. [C1-S2]

The same Big Technology interview reported that Klarna's workforce had fallen about 40%, from 5,527 in December 2022 to 3,422 in December 2024. That broader company-reported change should not be confused with the earlier 700-agent work-equivalence figure or attributed entirely to one assistant. [C1-S2]

What they did show was a more complicated operating choice: automate some work, retain people for other work, and keep adjusting the boundary.

For a founder, that is a more valuable lesson than either "AI replaces everyone" or "AI failed."

The question behind the excitement

When a founder asks whether agents can run a business, several questions are usually tangled together.

Can software read an incoming message and work out what the customer needs? Can it look up a current record? Can it prepare a useful answer? Can it act in a connected system? Can it keep working after the founder closes the laptop? Can it notice that something went wrong? Can it decide what the business ought to become?

These questions sit at different levels of responsibility.

An agent might be allowed to prepare a sponsorship proposal but not send it. It might be allowed to collect product information but not change the product's price. It might be allowed to flag an overdue invoice but not threaten a customer. It might be allowed to assemble a hiring brief but not select a person to hire.

Those are proposed design boundaries, not a claim that all software lacks the technical ability to perform the actions. A system can have the ability to send an email while lacking permission to send this email to this person.

That distinction is the center of this report.

We will use "agentification" to mean redesigning defined work so software can interpret information, choose useful steps, use connected tools and finish within explicit boundaries. This is an editorial definition for the book, not an official industry certification.

The ambition is real work. The boundary is real responsibility.

What is an agent, in ordinary language?

Imagine you ask a basic chatbot to draft a follow-up to a sales enquiry. It gives you some words. You copy them into your email system, check the customer's history, confirm the price and press Send yourself.

Now imagine a designed agent workflow. It receives the enquiry from an approved inbox, checks the current customer record, reads the approved offer, identifies an unanswered question, prepares a response and places it in a review queue. After a person approves the actual recipient and message, the system sends it and records the result.

The second example is an illustrative design. Whether it can be implemented in your chosen product depends on its connectors, account permissions and approval mechanisms. Current official documentation does support the underlying building blocks: connected tools, event or scheduled triggers, state and human review. [C1-S3, C1-S4, C1-S5]

The useful distinction is that the agent has a way to interact with its environment. It does more than generate a sentence. It can select a tool, inspect the result and choose what to do next.

Anthropic's engineering guidance distinguishes predefined workflows from agents that dynamically direct their processes and tool use. The terms are not used identically by every vendor, and the guidance itself notes that its tooling landscape has changed since its original publication in December 2024. [C1-S6]

You do not need to win a terminology argument before improving your business. You need to know where a fixed process is sufficient and where flexible reasoning actually helps.

If a form is missing an email address, a simple rule can flag it. If an enquiry combines a product question, a complaint and a request for a different payment plan, interpretation may be useful. Use reasoning where you need interpretation. Use rules where the answer is already fixed.

A model is not a business system

A language model is the component that interprets the information supplied to it and generates a response or proposed action. OpenAI describes its models as learning patterns during training and using learned parameters to generate content. The operational system around a model supplies the current task, tools and information. [C1-S7]

A capable model without access to your current price sheet can still quote an obsolete price. A model with access to the price sheet but no permission boundary can still propose an inappropriate discount. A model with the right price and permission can still fail if the email connection is broken and nobody checks the result.

These are illustrative failure cases. They show why buying access to a model does not amount to buying an operating company.

The complete system needs more than a clever answer. It needs a reliable way to start, enough relevant information, a small set of useful actions, a record of progress, a way to pause and a way to recover.

Think of a delivery business. A route planner can choose a route, but it is not the van, the driver contract, the parcel inventory, the proof of delivery or the customer-service policy. The route planner matters because it sits inside a larger operation.

An agent's model is important for the same reason. The surrounding design determines whether its capability becomes useful work.

The store assistant that makes the boundary visible

Shopify offers another grounded example. Its current Sidekick documentation describes an AI-enabled commerce assistant in the merchant's admin. It can help with guidance, content, app creation and tasks, using the context of the store. The documentation says changes are presented for review before being applied. It also says longer tasks can continue in the background and notify the merchant when ready for review. [C1-S8]

The setup guidance makes two limits especially clear: Sidekick cannot talk to customers or handle customer-support conversations on the merchant's behalf, and it cannot change the store without the merchant's approval. [C1-S9]

This is not a contradiction of the agent promise. It is a product choosing a useful boundary.

A founder can receive prepared work without surrendering control over everything the customer sees. Background work and human review can coexist. "Works after I close the chat" does not have to mean "makes every business commitment without me."

For a commerce operator, this may be a better starting point than a dramatic virtual-executive dashboard. The assistant begins near the records and actions that matter. The merchant stays at the point where a proposed change becomes a real change.

What 24/7 does and does not establish

An event-triggered system can start when a defined event occurs. A scheduled system can start at a defined interval. Microsoft Copilot Studio, Zapier Agents and n8n document versions of these capabilities. The availability of a specific trigger depends on the product and configuration. [C1-S3, C1-S4, C1-S10]

That supports a practical claim: work can begin outside the founder's working hours.

It does not support a universal claim of continuous correct operation. Connections can fail. A required source can be unavailable. A question can be ambiguous. An action can require approval. These are operating conditions your design should handle, not details to wish away with the phrase "autonomous."

The report uses three separate questions:

Availability: can the system receive and begin the job?

Reliability: can it repeatedly reach the right result on this workload?

Authority: may it take this action without another approval?

A system can score well on the first and poorly on the second. It can score well on the first two and still properly stop at the third.

A useful review queue is not proof that the system failed. It may be proof that it respected the boundary you gave it.

The promise should be smaller, and more valuable

"Replace your executive team" is an exciting sentence. "Prepare every inbound enquiry using current records and bring only the decisions to you" is a more useful contract.

The second sentence tells you what the system receives, what it does and where you remain responsible. It gives you a result you can inspect. It allows you to measure whether the work is faster or simply moved from execution to correction.

Our recommendation is to begin with one bounded job. Choose an input you understand, an output you can judge and a failure you can contain.

For a content business, that could be converting an approved research brief into a sourced draft. For a merchant, it could be preparing product-description changes for review. For a service business, it could be creating an internal enquiry brief. These are proposed pilots, not claims that a particular product will implement them unchanged.

The pilot should have a visible owner. It should state which actions may happen automatically. It should know what to do when information is missing. It should record what it actually finished, rather than declaring victory because it generated a plan.

The rest of the anatomy

The paid chapters go beneath the interface. We follow a job through its entire lifecycle, explain where model capability comes from, and separate context, memory and live truth. We look at tools, APIs, browsers and MCP. We explain why a personality file cannot create permission or intelligence. We examine short operating loops, teams, approval gates, evaluation and economics.

The business chapters then apply those ideas to revenue, marketing and the founder's daily decisions. The closing case distinguishes work already demonstrated from workflows that remain to be built.

This is a field guide for a business owner, not a promise that a specific model can manage every business. Product details are dated. Company results are attributed. Worked examples are labeled. Recommendations are recommendations.

The central question stays the same throughout:

What can this system be trusted to finish, with what information, under whose authority, and how will we know?

If you can answer that clearly for one job, you have a starting point.

You do not need an artificial CEO to take the first step. You need a clear task, a current source, a useful tool and a boundary that holds.

Chapter 1 source notes

[C1-S1] Klarna announcement, February 27, 2024. Company-reported first-month results and projected financial effect; not an independent audit.
https://www.klarna.com/international/press/klarna-ai-assistant-handles-two-thirds-of-customer-service-chats-in-its-first-month/
[C1-S2] Big Technology, Alex Kantrowitz, May 16, 2025. Interview with Klarna CEO; reported claims and explanation of human hiring.
https://www.bigtechnology.com/p/klarna-ceo-were-giving-ai-more-customer
[C1-S3] Microsoft, event triggers overview. Features and constraints, read October 9, 2026.
https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about
[C1-S4] Zapier Agents guide. Triggers, connected actions and activity log, read October 9, 2026.
https://zapier.com/blog/zapier-agents-guide/
[C1-S5] OpenAI, guardrails and human review. Tool-approval mechanisms, read October 9, 2026.
https://developers.openai.com/api/docs/guides/agents/guardrails-approvals
[C1-S6] Anthropic, Building Effective AI Agents. Originally published December 19, 2024; current page includes later updates.
https://www.anthropic.com/engineering/building-effective-agents
[C1-S7] OpenAI model-development explanation, read October 9, 2026.
https://help.openai.com/en/articles/7842364-how-chatgpt-and-our-language-models-are-developed
[C1-S8] Shopify Sidekick overview, current documented capabilities.
https://help.shopify.com/en/manual/ai-powered-tools/sidekick
[C1-S9] Shopify Sidekick setup and limitations.
https://help.shopify.com/en/manual/ai-powered-tools/sidekick/set-up
[C1-S10] n8n Agents documentation, Preview feature distinct from AI Agent node.
https://docs.n8n.io/build/build-and-manage-agents

---