How one person can run an IT company with AI agents

In Brief
This is the story of an IT company that sells PCs, servers, printers, monitors, toner, mice, keyboards, network equipment and consulting hours.
Before, the workday was divided among many people:
- A salesperson entered orders.
- Purchasing ordered goods.
- Logistics tracked deliveries.
- Customer service answered customers.
- Accounting approved invoices.
- Someone checked backorders.
- Someone chased suppliers.
- Someone cleaned up when something went wrong.
Now the same company is organized as an agent-driven operations system.
That doesn't mean people are gone. It means one person can sit as an operator, much like an air traffic controller, steering many small digital coworkers that each do their own job.
Before, people sat inside their own departments and carried cases between each other. Now the cases flow through a system, and the human handles the exceptions.
Podcast
AI-generated with Google's NotebookLM from this article.
Related reading:
The company
Let's call the company Nordlys IT AS.
They sell to businesses, schools, housing cooperatives, small municipalities, consulting firms and private customers with a business account.
They have three important departments:
1. Purchasing and logistics
They make sure goods are ordered, delivered, followed up and forwarded to the customer.
2. Customer service
They answer questions, delays, returns, complaints, exchanges and wrong orders.
3. Accounting
They handle invoices, credit notes, vouchers, approvals, bookkeeping, reconciliation and payment.
In a traditional company this would have been three small teams. Perhaps 6–12 people in total, depending on volume.
In the new model this is organized as three agent departments.
The suppliers
Nordlys IT uses three made-up suppliers:
| Supplier | What they're good at | Weakness |
|---|---|---|
| Fjordbit AS | PCs, monitors, docking, keyboards | A little slow on backorders |
| TonerTroll AS | Toner, ink, printers, supplies | Often splits deliveries |
| Skruvatronikk AS | Servers, networking, storage and specialty kit | Best on technical goods, but pricier shipping |
These don't exist in reality here. They're just made up for the story.
Before the workday begins
It's 07:58.
One person logs in.
Let's call her Maja.
Maja isn't a "buyer", "accountant" or "customer service agent" in the old sense.
She is the operations operator for the trade flow.
She runs the agents.
On her screen she doesn't have 19 systems open. She has one control panel.
There she sees:
- New orders
- Orders missing items
- Supplier purchase orders
- Goods on backorder
- Shipments on their way
- Invoices needing review
- Returns
- Customer cases
- Exceptions that need human judgement
It looks a bit like a control tower at an airport.
The aircraft are orders. The runways are suppliers. The weather is stock levels, freight, price changes and customer demands. The agents are the control system that keeps everything moving.
The agents
Nordlys IT has several agents. Each agent has one clear job.
| Agent | Job |
|---|---|
| Order Agent | Picks up orders from sales, the webshop and email |
| Stock Agent | Checks stock, price, lead time and alternatives |
| Purchasing Agent | Proposes or places orders with suppliers |
| Backorder Agent | Tracks items that are delayed or unconfirmed |
| Delivery Agent | Follows tracking, parcels and delivery dates |
| Customer Service Agent | Drafts replies to customers and updates cases |
| Return Agent | Handles returns, complaints and exchanges |
| Invoice Agent | Reads invoices from email and EHF |
| Reconciliation Agent | Matches order, goods receipt and invoice |
| Accounting Agent | Suggests bookkeeping and forwards exceptions for approval |
| Control Agent | Watches rules, amount limits and risk |
EHF stands for "elektronisk handelsformat" — electronic commerce format. It's a common way to send electronic invoices in Norway.
Morning: orders start coming in
At 08:07 the first order of the day arrives.
A customer, Jeløy Kjøtt & Data AS, has ordered through the webshop:
- 6 laptops
- 6 docking stations
- 6 monitors
- 6 wireless mice
- 6 keyboards
- 1 consulting package for setup
The order goes straight into the system.
Before, a person might have looked at the order, checked stock, emailed purchasing, waited for an answer, then updated the customer.
Now this happens in seconds.
The Order Agent says:
New order received. Customer approved. Payment terms OK. No credit hold. Products need to be checked against stock and supplier.
The Stock Agent checks internal inventory.
Result:
| Product | In our stock | Missing |
|---|---|---|
| PCs | 2 | 4 |
| Docking stations | 6 | 0 |
| Monitors | 4 | 2 |
| Mice | 10 | 0 |
| Keyboards | 10 | 0 |
The system understands that the order can be delivered in part, but the customer has chosen "combined delivery".
That means: don't send half if it creates a mess for the customer.
Purchasing: the agent checks suppliers
The Purchasing Agent goes out and checks the three suppliers.
| Supplier | PCs | Monitors | Delivery | Comment |
|---|---|---|---|---|
| Fjordbit | 4 in stock | 0 | 2–3 days | Good price on PCs |
| TonerTroll | 0 | 2 in stock | 1–2 days | Good on monitors |
| Skruvatronikk | 4 in stock | 2 in stock | Next day | Pricier, but fastest |
In the old days the buyer might have called around, checked portals, sent emails and compared by hand.
Now the agent does this as a sort of mini-tender every time.
It weighs:
- Price
- Freight
- Lead time
- The customer's requested date
- Past supplier reliability
- Whether the item is critical
- Whether everything can ship together
- Whether the margin is still healthy
The Purchasing Agent proposes:
Order the missing PCs and monitors from Skruvatronikk. They're more expensive, but can ship everything together tomorrow. The margin drops by 2.4 percentage points, but the customer gets a quick delivery.
Maja gets the proposal on her screen.
She clicks approve.
The order goes to Skruvatronikk.
At the same time: a salesperson enters a manual order
At 08:42 a salesperson enters an order from a larger customer.
The customer is called Moss Drift AS.
They need:
- 1 small server
- 4 disks
- 1 backup solution
- 1 network switch
- 8 hours of consulting
This isn't a simple webshop order. Here the salesperson has had a dialogue with the customer. Notes sit in the CRM system.
The Order Agent reads the order and pulls up the sales note:
Customer must have delivery by Friday because the old server has an unstable disk. Consultant to be booked after equipment is delivered.
The system then understands this is more critical than usual.
The Stock Agent checks inventory.
The server isn't in our stock.
Skruvatronikk has the server, but the switch is on backorder.
Fjordbit has the switch, but not the server.
The Purchasing Agent proposes a split purchase:
- Server from Skruvatronikk
- Switch from Fjordbit
- Disks from our own stock
- Backup license digital
The Delivery Agent checks whether everything can be with the customer before Friday.
It says:
Yes, if the server is ordered before 11:00 and the switch before 13:00.
Maja approves.
At the same time, the Consultant Agent creates a draft internal task:
Book technician Thursday or Friday after expected delivery.
Now one order has already connected sales, purchasing, logistics and consulting planning.
Backorders: where things usually start to unravel
At 10:15 what always happens in real life happens.
Skruvatronikk sends an order confirmation.
But there's a problem.
They can deliver the PCs to Jeløy Kjøtt & Data, but the monitors are suddenly on backorder.
New expected date: in 9 days.
This is everyday life in IT distribution.
Goods move fast. Stock can look green at 08:20 and red at 10:15.
In the old days this could have gone unnoticed until the customer called and asked:
"Hey, where are our monitors?"
By then the customer is already annoyed.
In the new system the Backorder Agent has a standing job:
- Check all open purchase orders several times a day
- Catch changed delivery dates
- Compare against the customer's requested date
- Find an alternative supplier
- Propose cancellation or partial change
- Alert customer service if the customer needs to be informed
The Backorder Agent says:
Exception found. Monitors for Jeløy Kjøtt & Data have moved from next day to 9 days. Customer chose combined delivery. Alternative available at TonerTroll with delivery in 1–2 days. Price is 3 percent higher. Suggest cancelling the monitors at Skruvatronikk and ordering them from TonerTroll.
Maja looks at the proposal.
She also sees that the customer is new and that this is their first order.
In that case fast delivery is more important than perfect margin.
She approves.
The agent does three things:
- Cancels the monitors at Skruvatronikk.
- Orders the monitors from TonerTroll.
- Updates the order with a new expected combined delivery.
The Customer Service Agent at the same time drafts a message:
Hi! We've optimized your delivery so the full order can still be delivered quickly. One item was moved to another supplier to avoid delay. We're following the shipment closely and will let you know when it ships.
Maja approves the message.
The customer doesn't notice the chaos behind the scenes. The customer only notices that the company is paying attention.
Customer service: from firefighting to proactive follow-up
At 11:03 a customer sends an email:
Hi, we ordered toner yesterday. Has it shipped?
This is a simple case, but simple cases like this eat a lot of time when they arrive all day long.
The Customer Service Agent finds the order.
TonerTroll has shipped one of three toners. Two are on backorder, expected in stock tomorrow.
The agent drafts a reply:
Hi! One toner has already shipped and is on its way. The two remaining are confirmed at the supplier tomorrow and will be shipped onward as soon as they're ready. We follow up automatically and will let you know if the date changes.
But the agent doesn't stop there.
It checks whether alternatives exist.
Fjordbit has a similar toner in stock, but the item has a different manufacturer number. The Stock Agent is uncertain about compatibility.
The case is then escalated to Maja:
Possible alternative toner found, but compatibility isn't 100 percent confirmed. Requires human judgement before swap.
This is the core:
The agent handles the normal. The human handles doubt, accountability and judgement.
Maja checks the product, sees that it isn't identical, and chooses to wait for the original toner.
The Customer Service Agent sends the reply.
The case closes automatically with an internal note:
Customer informed. No action needed unless delivery date changes.
Lunch: the system works while people eat
At 12:00 Maja takes lunch.
The system doesn't stop.
The agents keep going.
The Backorder Agent runs a fresh check.
The Delivery Agent checks tracking.
The Invoice Agent reads incoming invoices.
The Reconciliation Agent matches invoices against orders and goods receipts.
The Customer Service Agent sorts new inquiries by severity.
When Maja comes back, there aren't 43 unread emails waiting.
There are 7 cases that actually need a decision.
That is an enormous difference.
Accounting: the invoice arrives
At 12:37 an invoice arrives from Fjordbit.
It comes as EHF, an electronic invoice.
The Invoice Agent reads the invoice.
It finds:
- Supplier name
- Organization number
- Invoice number
- Due date
- Order number
- Item number
- Quantity
- Price
- VAT
- Freight
- Total amount
The Reconciliation Agent then does a three-way match.
A three-way match means:
Does the invoice match the purchase order? Does it match the goods we actually received? Do price and quantity match?
There are three documents that need to fit together:
| Document | What it shows |
|---|---|
| Purchase order | What we ordered |
| Goods receipt | What we actually received |
| Invoice | What the supplier wants to be paid for |
If all three match, the invoice is safer to post.
The first invoice goes straight through
The invoice from Fjordbit covers the switch for Moss Drift.
Everything matches:
- Right supplier
- Right purchase order
- Right price
- Right quantity
- Item received
- Freight within agreed level
- VAT correct
- Amount below the auto-approval limit
The Accounting Agent proposes posting:
- Cost of goods
- Input VAT
- Accounts payable
- Project/customer order link
The Control Agent says:
Low risk. Can be posted automatically per policy.
Maja doesn't need to do anything.
The invoice is posted and queued for payment after the due date.
The second invoice stops
At 13:04 a PDF invoice arrives by email from TonerTroll.
It covers the monitors for Jeløy Kjøtt & Data.
The Invoice Agent reads the PDF and finds the order.
But something is off.
The invoice has:
- 2 monitors
- Correct item number
- Correct customer order
- But higher freight than expected
The Reconciliation Agent says:
Exception: Freight amount is 249 kroner higher than expected. Total is within the low-amount limit, but deviates from the purchase order.
In a traditional accounting department someone might have emailed purchasing:
Hey, do you know why this freight is higher?
Purchasing would have replied later.
Customer service might have been involved.
The invoice might have been left sitting.
Here it goes differently.
The agent checks history:
- The order was moved from Skruvatronikk to TonerTroll because of a backorder.
- Faster delivery was chosen.
- Express shipping was accepted by Maja at 10:21.
Then the system understands the exception.
The Accounting Agent says:
Freight exception explained by approved supplier switch and express shipping. Documentation is in the order log. Suggest approval.
Maja approves.
The invoice is posted.
What matters here isn't that the agent "took over accounting". What matters is that the agent found the connection between purchasing, logistics, customer order and invoice.
Returns: the customer ordered the wrong thing
At 13:42 a customer service inquiry comes in.
A customer has ordered the wrong toner.
They've opened the packaging, but haven't used the toner.
Before, this would have become a little merry-go-round:
- Customer service checks the order.
- Customer service asks purchasing whether the supplier accepts returns.
- Purchasing checks supplier terms.
- Accounting needs to know if a credit note is coming.
- The warehouse needs to know if the item goes back or into own stock.
- The customer waits.
Now the Return Agent kicks in.
It checks:
- Which order does this concern?
- Which item?
- Who delivered it?
- What do the supplier's return rules say?
- Is the packaging broken?
- Is this a special-order item?
- Is the item within the return window?
- Should the customer get a new item?
- Should a credit note be issued?
- Does the item go back to the supplier or into our own stock?
The Return Agent finds:
- The item came from TonerTroll.
- TonerTroll accepts returns within 14 days if the inner packaging is intact.
- The customer has opened the outer packaging, but not the inner one.
- The correct toner is in stock at Fjordbit.
The agent proposes:
- Open a return against TonerTroll.
- Send the customer a return label.
- Order the correct toner from Fjordbit.
- Invoice the customer for the new toner.
- Credit the wrong toner once the supplier's credit note arrives.
- Link the case to the original order.
The Customer Service Agent drafts a friendly reply to the customer.
The Accounting Agent creates an expected credit note.
The Purchasing Agent orders the correct toner.
Maja sees that the case is clean and approves.
When everything goes well, the agents work quietly
Most things don't need human intervention.
Examples of cases that go through automatically:
| Event | Agent handling |
|---|---|
| Customer orders an in-stock item | Order confirmed and sent to picking |
| Supplier confirms delivery | Order status updated |
| Parcel is shipped | Tracking link sent to customer |
| Invoice matches order | Posted automatically |
| Customer asks about status | Agent answers based on order data |
| Item is on backorder | Agent searches for alternative |
| Return is simple | Return case opened from template |
| Consulting hour to be booked | Suggests time and resource |
It's not the case that one big AI does everything.
It's more like a small digital organization:
Many small agents with small areas of responsibility. One human operator with overview and decision authority.
When something is unclear, the system stops
A good agent system shouldn't just be fast. It should also know when to stop.
Examples of cases that go to Maja:
| Exception | Why a human must step in |
|---|---|
| Supplier price has risen sharply | Affects margin and customer price |
| Replacement item isn't quite the same | Risk of error at the customer |
| Invoice is missing an order number | Risk of misposting |
| Customer is unhappy | Requires tone, judgement, ownership |
| Return is outside the window | Requires a commercial call |
| Large order with thin margin | Needs strategic review |
| Server configuration is unclear | Technical risk |
| Credit hold on the customer | Financial responsibility |
| VAT looks wrong | Accounting risk |
| Supplier has changed the delivery date several times | Customer may need an alternative |
This matters.
AI agents shouldn't just "do as much as possible". They should do as much as possible safely.
Afternoon: one order ties everything together
At 14:18 a new order arrives from the webshop.
The customer orders:
- 20 monitors
- 20 docking stations
- 20 mice
- 20 keyboards
- 20 headsets
This looks simple, but the agents notice something.
The customer is a consulting firm that often orders equipment for new hires. In the past they've had returns because they picked the wrong docking station for the PC model.
The Stock Agent checks the customer's history.
It says:
Possible risk: Customer has previously returned docking stations due to wrong USB-C/Thunderbolt compatibility. Suggest asking the customer to confirm PC model before purchasing.
The Customer Service Agent drafts a message:
Hi! Before we ship the docking stations, we just want to confirm which PC model they'll be used with. That way we avoid the wrong docking type and delays for the staff who are getting the equipment.
Maja approves.
The customer replies after 20 minutes.
It turns out that half the staff have a different PC model than before.
The agent updates the recommended docking station.
The Purchasing Agent adjusts the order.
The Accounting Agent updates expected cost and margin.
The Customer Service Agent confirms the new delivery.
This is a good example of the difference between a passive and an active system.
A passive system accepts orders.
An active agent system asks:
Is this order likely to be correct?
End of day: Maja doesn't get a pile, she gets a summary
At 15:48 Maja asks for a daily summary.
The system replies:
Today's key numbers
| Area | Status |
|---|---|
| New customer orders | 27 |
| Automatic purchases | 18 |
| Purchases approved by Maja | 6 |
| Backorders caught before customer complained | 4 |
| Customer cases resolved automatically | 31 |
| Customer cases escalated | 5 |
| Invoices received | 19 |
| Invoices posted automatically | 14 |
| Invoices with exceptions | 5 |
| Returns opened | 3 |
Most important exceptions
| Case | Action |
|---|---|
| Monitors for Jeløy Kjøtt & Data on backorder | Switched supplier to TonerTroll |
| Server order for Moss Drift | Split purchase, delivery before Friday |
| Wrong toner at customer | Return opened, correct item ordered |
| Freight exception on invoice | Explained by approved express shipping |
| Docking risk at consulting customer | Customer confirmed PC models before delivery |
Suggested improvements
The system also proposes three improvements:
- Add a rule: When a customer orders docking stations in larger quantities, ask for PC model if unknown.
- Add a rule: If a supplier changes delivery by more than 3 days, automatically check alternatives.
- Add a rule: Express shipping under 500 kroner can be approved automatically if it saves the customer's requested delivery date.
This is the self-improving part.
Every day the system learns a little more about how the company actually works.
How this looked before
Before, the workday looked roughly like this:
Customer order → salesperson → purchasing → supplier portal → email → customer service → another email → invoice → accounting → question to purchasing → waiting → chasing → customer calls → someone digs around → someone fixes it.
It wasn't necessarily bad. It was just heavy.
Information was scattered:
- A little in email
- A little in ERP
- A little in the webshop
- A little at the supplier
- A little in the buyer's head
- A little in the accountant's head
- A little at customer service
- A little at sales
When someone quit, a lot of practical knowledge often disappeared with them.
How it looks now
Now the flow looks like this:
Customer order → the agents read, check, propose, act, document → the human approves exceptions → the system learns.
The difference is that knowledge no longer lives only in people's heads.
It lives in:
- Rules
- Agent instructions
- Approval limits
- Logs
- History
- Supplier data
- Customer profiles
- Exception routines
- Documented decisions
This is essentially the same principle as Claude Code in large codebases.
Claude Code needs CLAUDE.md, hooks, skills and tools to understand the codebase.
An IT company needs the same, only for operations:
| Claude Code world | IT company world |
|---|---|
CLAUDE.md | The company's working rules |
| Hooks | Automatic checks |
| Skills | Specialized agent roles |
| MCP | Connections to ERP, CRM, email, suppliers and accounting |
| LSP | Precise understanding of where data belongs |
| Subagents | Small agents that investigate cases on their own |
| Pull request | Human approval before an important change |
| Test/lint | Accounting checks, order reconciliation and margin checks |
The most important point
The old company was organized around departments.
The new company is organized around flow.
Before:
"This is a purchasing case." "This is an accounting case." "This is a customer service case."
Now:
"This is one customer order moving through the entire machine."
It's the same case all the way through:
- The customer buys.
- The order is registered.
- Stock is checked.
- A supplier is chosen.
- Goods are ordered.
- Backorders are monitored.
- Delivery is tracked.
- The customer is informed.
- An invoice arrives.
- The invoice is matched.
- The invoice is posted.
- Returns are handled if anything goes wrong.
- The system learns from exceptions.
Where one person actually comes in
Maja doesn't do everything by hand.
She does this:
- Sets rules
- Approves exceptions
- Assesses risk
- Makes commercial decisions
- Changes priorities
- Talks to important customers when needed
- Overrides the agents when necessary
- Improves the system
She's no longer the one moving paper from A to B.
She's the one steering the flow.
That's an enormous difference.
The old role was case handler. The new role is operator, controller and system trainer.
A simple way to explain this
Think of a restaurant.
Before, you had one person who took the order, one who shouted to the kitchen, one who checked stock, one who called the supplier, one who took payment, one who answered the customer if the food was delayed.
In the agent system you still have all those functions.
But they're connected.
When the customer orders fish, the system automatically checks:
- Do we have fish?
- If not, which supplier has fish?
- When can it be delivered?
- What does it cost?
- Does it affect margin?
- Does the customer need to be informed?
- Does the invoice match afterwards?
The human no longer needs to run between the rooms.
The human stands at the control panel.
How the whole agent organization can be described
The purchasing department
The Purchasing Agents make sure the company buys the right item, from the right supplier, at the right price, at the right time.
They check:
- Stock levels
- Supplier price
- Lead time
- Freight
- Alternatives
- Backorders
- Margin
- Past supplier reliability
They don't just "buy cheapest".
They weigh the whole picture.
Cheapest isn't always best if the customer needs the item tomorrow.
The logistics side
The Logistics Agents watch the movement.
They check:
- Is the item shipped?
- Do we have a tracking number?
- Is the parcel delayed?
- Is everything arriving together?
- Should something be partially shipped?
- Has the item been received?
- Should the customer be notified?
- Should a consultant be booked after delivery?
Logistics isn't just freight. It's the rhythm of the entire order process.
The customer service department
The Customer Service Agents take care of the dialogue.
They answer:
- Where is my order?
- Can I change the delivery address?
- Can I return this item?
- Is this the right toner?
- Can you send me a tracking number?
- When will the rest arrive?
- Can we get a copy of the invoice?
- What do we do when the product doesn't work?
But most importantly:
They don't just answer in text. They connect to the facts.
A good customer service agent should never guess. It should pull status from order, stock, supplier, freight and invoice.
The accounting department
The Accounting Agents make sure the money adds up.
They check:
- Does the invoice match the order?
- Does the invoice match the goods receipt?
- Is the VAT correct?
- Is the supplier correct?
- Is the account number known?
- Is the amount within the agreement?
- Should the invoice be approved?
- Is there a credit note?
- Has the item been returned?
- Should the cost be linked to a customer order?
Accounting doesn't just become "bookkeeping afterwards".
It becomes a control engine inside operations.
The big win
This isn't first and foremost about saving time on one task.
The win is that the whole flow becomes more coherent.
The customer doesn't have to experience the company as siloed.
Before, the customer might hear:
"I'll have to check with purchasing." "Accounting has to look at that." "It's with the supplier." "I can't find the case."
Now the Customer Service Agent can see the whole picture:
- Order
- Purchasing
- Supplier status
- Freight
- Invoice
- Return
- Prior dialogue
The company is then experienced as one system, not three departments emailing each other.
The new everyday life in one sentence
A modern agent-driven IT company can work like this:
One customer order starts a chain of small, controlled agent actions across purchasing, logistics, customer service and accounting, while one human handles the exceptions, the risk and the improvement of the system.
That's the whole point.
Not that AI "replaces everything".
But that AI makes it possible for one capable person to run an operation that previously required a whole small administration.
What this story actually shows
This is a prime example of AI-native operations.
Because it isn't about putting a chatbot on top of old systems.
It's about changing how work flows.
Before, the company was built around departments.
Now the company is built around processes, data, rules and agents.
The old question was:
Who will do this task?
The new question is:
Can the system handle this safely on its own, or does it need human judgement?
That's the whole shift.
Glossary
| Term | Definition |
|---|---|
| AI agent | An AI system that doesn't just answer, but can use tools, read data, propose actions and carry out multiple steps to solve a task. |
| Agent-driven operations system | A company organized around the flow of work rather than around departments. Small specialist agents handle the normal cases, and a human handles exceptions and risk. |
| Operator | The human who runs the agents. Sets rules, approves exceptions, assesses risk and improves the system. Closer to an air traffic controller than a case handler. |
| EHF | "Elektronisk handelsformat" — Norway's standard format for electronic invoices that can be read and reconciled automatically. |
| Three-way match | Reconciliation method where the purchase order, the goods receipt and the invoice are compared. If all three match, the invoice is safer to post. |
| Backorder | An item that has been ordered but not yet delivered. The supplier still owes the goods. |
| Margin | The difference between a company's cost price and its selling price. Often measured in percent and drives the profitability of an order. |
| ERP | Enterprise Resource Planning. A shared business system for orders, stock, accounting and logistics. |
| CRM | Customer Relationship Management. A system for customer data, dialogue, sales opportunities and follow-up. |
CLAUDE.md | A rules file that tells Claude Code how a project works. In the operations analogy, it corresponds to the company's working rules. |
| Hooks | Rule-based control points that run automatically at specific places in the workflow. Used for logging, validation or security checks. |
| Skills | Reusable skill packages that teach an agent how to do a specific kind of task in a specific way. Corresponds to specialized agent roles. |
| MCP | Model Context Protocol. An open standard for connecting AI agents to external tools and systems like ERP, CRM, email and supplier portals. |
| LSP | Language Server Protocol. A standard that lets tools understand where data and symbols belong. In the operations analogy: precise understanding of what belongs where. |
| Subagents | Small specialist agents that each investigate one part of a case before the result is brought together as a whole. |
Sources and resources
- How Claude Code works in large codebases (Anthropic) — Anthropic's blog post on how Claude Code operates inside large codebases. Reference frame for the building blocks (CLAUDE.md, hooks, skills, MCP, subagents) that the story applies to an operations organization.