Five jobs, run for real.

For accountants

What is still owed, and by whom?

A bookkeeper has a quarter's invoices and the payments that came in against them — including one invoice paid in two instalments and one payment recorded under a differently written reference.

The folder

• invoices.csv — 12 invoices
• payments.csv — 10 payments

The request

“Reconcile invoices.csv against payments.csv. Which invoices are unpaid or only part-paid, and how much is still owed on each? Put them in a spreadsheet called outstanding.xlsx with a total for each client, and tell me the total outstanding.”

What it did

1. Planned the job in five steps and read both files.
2. Asked before running a short script to match payments to invoices: bash(powershell …) · execute. It ran in Karkhana's sandbox, confined to this folder and unable to open internet connections. The script treated “inv 1005” and “INV-1005” as the same invoice.
3. Worked out every figure with its calculator, so the arithmetic is on the record: 2275.75-2000 = 275.75 sum(275.75,3890.25) = 4166 sum(275.75,480,960,3890.25,745) = 6351
4. Asked before writing the spreadsheet: create_xlsx(outstanding.xlsx) · write
5. Checked the result — its check read the finished spreadsheet and confirmed the figures first time — then answered.

What it produced

outstanding.xlsx, as written: the invoices still owed, then a total for each client.

Worth knowing

• Every figure is correct, including the invoice paid in two parts, which it correctly left out as fully paid.
• It matched payments by their reference. A payment with no reference, or one covering several invoices, still needs a person's judgement.
• Commands run only in the sandbox and, in this mode, only after you say yes; the sandbox cannot open internet connections.

For property managers

What does the building earn, and what falls due next year?

A property manager has six leases for one building, with the rent stated three different ways — and a side letter that quietly changed one of them.

The folder

• unit-1-hollin-bakery-lease.docx
• unit-2-marlow-opticians-lease.docx
• unit-3-greaves-holt-lease.docx
• unit-4-tillys-coffee-lease.docx
• unit-5-pennine-cycles-lease.docx
• unit-5-pennine-side-letter-2026.docx
• unit-6-ardent-dental-lease.docx

The request

“Today is 1 October 2026. Go through every document in this folder and make a spreadsheet called leases.xlsx with one row per unit: the tenant, the annual rent, the next rent review date, and any break option with the last day notice can be given. Flag every rent review or break date that falls in 2027, and tell me the total annual rent across the building.”

What it did

1. Planned the job in six steps.
2. Read all seven documents, the side letter included.
3. Worked out the rent roll with its calculator — one rent is quarterly and one is per square foot: 28000 + (9250*4) + (22.50*1800) + 18600 + 31500 + 45000 = 200600
4. Was sent back by its check for answering before the spreadsheet existed, then asked before writing it: create_xlsx(leases.xlsx) · write
5. Was sent back again — its check read the spreadsheet and found two real mistakes (below).
6. Asked again, rewrote the spreadsheet, and the check confirmed it.

What its check caught

“As of 1 October 2026, Unit 1’s 25 March 2026 rent review is already past, so it should not be recorded as the next rent review date. Also, the request asks to flag every rent review or break date falling in 2027; Unit 3 has a break date of 1 June 2027, but the spreadsheet flags the break/notice column as ‘No’ because the notice deadline is in 2026. That misses a 2027 break date.”

What it produced

leases.xlsx, as finally written. The highlighted rows are the three units with a 2027 date.

…and from its answer, in its own words:

Unit 5 — Pennine Cycle Works Ltd … Next rent review date: 24 June 2027 (2027 flag) … This review date comes from the 12 January 2026 side letter, which changes the next review from 24 June 2028 to 24 June 2027.

Total annual rent across the building: £200,600.

Worth knowing

• Every figure and date is correct, including the review date the side letter moved — the lease alone gives 2028.
• Unit 6's last day for break notice, 25 June 2026, has already passed. The spreadsheet gives the date without saying so; the request did not ask, and it is the kind of thing a person reading the sheet should still check.
• The dates were worked out by the AI, not the calculator, so check them against the leases before acting on one.

For educators — and any system with a connector

A lesson built inside another program

A teacher's school uses its own lesson-authoring system. Karkhana has never seen it: it was added in Settings by its address, as a connector — the open MCP standard — with the tools Karkhana may use ticked one by one. This time the work happens in that system, not in a folder.

The connection

A lesson-authoring system the school runs, offering tools for signing in, finding where a lesson should be filed, planning it, building it, checking it and publishing it — and marked in Settings as a system the teacher's own organisation runs.

The request

“Generate a lesson on Solar System for 5-year-olds”

What it did

1. Signed in first, because the system's own sign-in tool says to: start_auth · asked first The system answered with a link for the teacher to approve, so Karkhana stopped and handed it over — “Open this link … then click Approve. After approving, reply ‘continue’.” The message ended there, waiting for the teacher.
2. Asked where the lesson should go, one choice at a time, from what was already in the system: the subject (it suggested Science), then the course, then the category. The only category under that course was Plants; it suggested creating a Space category instead, and the teacher chose Plants.
3. Asked before each step that could change something on the other system, and was told yes for the session: lesson_curriculum_planner lesson_json_serializer lesson_structure_validator publish_lesson
4. Checked the lesson with the system's own validator before publishing: valid · 0 errors · 0 warnings
5. Published it, then stopped and asked before going further — the lesson still needed its pictures and voice.

What it produced

A published lesson: a welcome, five things in the sky to tap, a card for each that zooms in, plays a sentence and asks the child to say the word, and a goodbye. What the child hears, as written:

…and the end of its answer, in its own words:

The lesson structure validated successfully, but it is NOT READY FOR A CHILD YET: it still needs 7 images and 8 audio clips. As published right now, it will show placeholder/blank visuals and silent audio.

Please reply “yes, generate everything” if you want me to generate and save all images and audio now.

Worth knowing

• Nothing about this system is built into Karkhana. The order of the work — sign in, choose where it goes, plan, build, check, publish — came from the descriptions the system's own tools carry. Any system that offers an MCP connector is added the same way: its address in Settings, then the tools it may use.
• Because the teacher's own organisation runs this system and said so in Settings, its replies reach the AI as written. A system somebody else runs is read the safe way: the AI gets only the checked facts it asks for, never the system's own wording.
• Signing in is the teacher's to do, in their own browser. Karkhana handed the link over and waited; it never approves anything on the person's behalf.
• It ran the step that builds the lesson twice, about a minute each — the second time only to fix one label, where Saturn's had been given its whole sentence. When it made the pictures and voice in the next message, it asked for one audio clip twice with the same input; since this run, Karkhana does not send a call that changes something in a connected system again once the same call has already worked in that message, and the AI is told to use the earlier result.