Reservation Creation and Payment Reconciliation by an apeople

Le Mod Casa takes bookings conversationally on WhatsApp and payments by UPI, at any hour. Between a guest saying "paid" and a complete booking existing, a human had to open the payments mailbox, find the matching credit, judge the amount, check whether the guest had stayed before and at what rate, create the reservation, post the finance entry, and log the whole thing.

The problem is not that this work is slow. It is that it is multi-step, interrupt-driven and easy to leave half-done. Every step is a place to stop, and stopping produces the worst outcome available:

• a reservation with no payment posted against it;
• a payment received with no reservation created;
• a guest re-entered as new because nobody checked the master;
• a booking with no audit trail, discovered at month-end;
• a room verbally promised and never blocked.

Partial completion is worse than no completion, because it looks done. Someone believes the booking exists; the finance record disagrees; the discrepancy surfaces weeks later. That, not slowness, is the failure mode this case is about.

---

An apeople — Jeni De, an executive assistant holding a standing role across personal and Le Mod Casa property operations — instructed in natural language, executing end-to-end across five systems and returning a report with her evidence and her declared uncertainty.

Operating mode: assistant. The trigger is human; the execution is autonomous. The development objective is to remove the trigger.

---

The run as it happened, in five artifacts. The sequence between them is the case.

A note on time. Timestamps are stored in UTC and rendered in IST by the interface. Where the agent's narrative quotes a stored value it reports UTC; where the platform renders a value it shows IST. This is a storage-versus-display convention. All times below are stated in IST.

A returning guest asked for a room, paid by UPI over WhatsApp, and a verified booking existed in three systems of record ten minutes later. No human touched the reservation system, the finance ledger or the ticket queue.

Figure 1 — the guest exchange and the payment claim

Figure 1. WhatsApp thread, "[Guest thread withheld]." The guest confirms one night ("Perfect" / "Yes"); Le Mod Casa commits verbally — "Done, Will reserve one for you" — and sends the QR code; the guest returns a payment confirmation screenshot for ₹2,500.00, paid to Le Mod Casa, captioned "Done"; Le Mod Casa replies "Thanks."

Four things here matter more than they appear to.

• The room was held in a sentence, not in a system. "Done, Will reserve one for you" committed the unit before money moved, and existed nowhere but this thread until Jeni ran. In that interval the unit was neither held nor free.
• The screenshot carries no payment reference. Amount, payee, banking name, timestamp — no UTR, no gateway ID. This constrains what can be matched against (Finding 1).
• The payment was announced, not proven. Nothing in this image authorises a booking. That distinction is the architecture, and it held (Finding 4).
• The thread ends at "Thanks." No confirmation code ever reached the guest (Finding 6).

Figure 2 — the instruction

Figure 2. The instruction, issued on the CLI: "There is a past guest [Guest], +91 XXXXX XXXXX — we need to book a room for this saturday (01-Aug) for one night, please create a reservation for him for unit lmc_429, and reconcile the payments with the email as well."

One sentence of natural language. The division of labour it implies:

Supplied by the human	Left to Jeni
Guest name and mobile	Resolving the guest to a record ([guest id]) and confirming past-guest status
Date (01-Aug), duration (one night)	Creating the reservation and issuing a confirmation code
Unit (lmc_429)	Locating the payment claim on WhatsApp
The instruction to reconcile against email	Locating the matching credit and proving they are the same event
—	Determining the rate
—	Posting the finance ledger row
—	Opening, updating and closing the ticket

This instruction is the boundary between the current state and the target state. Today it is required. The development objective is that it should not be.

Figure 3 — the execution and reconciliation report

Figure 3. Jeni's report back to Alok. Reservation created (guest [guest id], unit lmc_429, 01–02 Aug, confirmation code [confirmation code redacted], res #3533, status Confirmed → Payment Received); payment reconciled (WhatsApp claim, matching Razorpay email pay_[redacted], ledger row posted in g8_ac_txn); one rate variance flagged — ₹2,699 listed vs ₹2,500 charged; ticket #2586 logged and closed.

Not a summary of work a person did — a report of work the agent did, with its evidence attached and its own uncertainty declared. Note the audience: this went to Alok, in chat. Compare Figure 5, which is what went into the permanent record (Finding 10).

Figure 4 — verification in the system of record

*Figure 4. Casa Admin App. Reservation Information: check-in 01-Aug-26, check-out 02-Aug-26, 1 night, 1 adult, 0 children, booked date 30-Jul-26. All Guests (1): primary guest [guest id] — [Guest name withheld], +91XXXXXXXXXX, INDIA, National_id on file with document image attached.*

This figure turns the case from a report into evidence. Jeni's account of what she did (Figure 3) is independently corroborated by the system of record (Figure 4) — guest ID, dates, occupancy and booking date all agree.

It also exposes what Figure 3 did not mention: Check-in Time and Check-out Time both read "Not set" (Finding 7). And the toolbar carries a Lodgify action — the distribution channel — whose sync status is unevidenced (Finding 8).

Figure 5 — the audit record

Figure 5. Ticket #2586, "Reservation for [Guest] at lmc_429 - 01 Aug (1 night)." Created 30-Jul-26, 18:45:54 IST. Completed 18:48:04 IST. Status Closed · Priority High · Category AI Agent Task · Department Admin · Assigned To Jenni De · Target not set.

*Brief: "Alok directed 2026-07-30: book past guest [Guest name withheld] (+91XXXXXXXXXX, g8_user_id [guest id]) into lmc_429 (GlassHouse, g8_prop_id 28) for Sat 01-Aug to Sun 02-Aug, 1 night. Reconcile payment against Gmail after booking. Jenni-De (Aperson, EA, handler=Alok)."*

Update #6669 · 18:47:24 IST · comment: "check." Update #6670 · 18:48:04 IST · close: "Reservation created for [Guest name withheld] (lmc_429, [confirmation code redacted], 01-02 Aug 2026, res#3533). Payment ₹2500 already made via Razorpay pay_[redacted] (matched WA screenshot + Gmail confirmation). Ledger posted (txn [txn redacted]), status=Payment Received."

The highest-yield artifact in the case, for three reasons.

It makes the run measurable. Created 18:45:54, completed 18:48:04 — 2 minutes 10 seconds from instruction to a booking existing in three systems. Against a guest payment at 18:38, roughly ten minutes from money to confirmed reservation.

It shows good governance infrastructure already exists. Category AI Agent Task, Department Admin, and handler=Alok written into the brief. Agent work is classified as a distinct, queryable category with a named accountable human. That is not common, and it is the strongest structural asset in the case.

And it shows what the permanent record omitted. The rate variance — the only judgement call in the entire run — appears in Figure 3 and appears nowhere in Figure 5 (Finding 10).

The reconciled sequence

All times IST.

Time	Event
18:13–18:26	Guest agrees one night
18:30	Verbal hold: "Done, Will reserve one for you"
18:31	QR code sent
18:38:39	Razorpay credit lands in email — ₹2,500.00, pay_[redacted]
18:38:49	Guest sends payment screenshot — ₹2,500.00, "Done"
18:41	"Thanks."
~18:45	Instruction issued to Jeni (Figure 2)
18:45:54	Ticket #2586 opened
18:47:24	Update #6669 — "check" (Finding 12)
18:48:04	Update #6670 — reservation created, payment reconciled, ledger posted, ticket closed
—	Verified in Casa Admin (Figure 4)

The credit arrived ten seconds before the claim — the bank notification was already in hand when the guest announced payment. That is the healthy sequence and it is not guaranteed; a guest can screenshot faster than a gateway can notify.

---

---

The harness

The model is not the story. The harness is: five systems, one instruction, 2 minutes 10 seconds.

Component	What it did in this run
WhatsApp (personal) — read	Located the guest thread; read the exchange and the payment screenshot
Email (Gmail) — read	Located the Razorpay notification; extracted amount and pay_[redacted]
Guest master — read	Resolved +91 XXXXX XXXXX → guest [guest id]; confirmed past-guest status; retrieved last stay's rate
Reservation system — write	Created res #3533, unit lmc_429 (GlassHouse, g8_prop_id 28), 01–02 Aug, code [confirmation code redacted], status Confirmed → Payment Received (verified, Fig 4)
Finance ledger (g8_ac_txn) — write	Posted ₹2,500, UPI, status=posted, txn_ref=pay_[redacted], ledger txn [txn redacted]
Ticket queue — write	Opened #2586, posted two updates, closed it with the trail (Fig 5)
Rate card — read	Retrieved listed nightly rate ₹2,699; compared against ₹2,500 quoted/paid; raised the variance

Two harness properties did the real work. Cross-channel retrieval — the agent could treat a WhatsApp thread and an email inbox as one evidence space, which is what made reconciliation possible at all. Write access to systems of record — without it this is a very good research assistant producing a very good recommendation, and a human still does the booking.

The harness itself is small: a 2 vCPU / 2 GB RAM virtual machine. That footprint is informative — the orchestration, credential handling and tool routing are light because the reasoning is remote. An operator sizing this should not budget for a GPU host.

AI-executed vs AI-assisted — the distinction is layered here

Reporting these under one heading is what makes AI benefit claims untrustworthy, so this case separates them explicitly:

Layer	Today	Target state
Trigger	Human. Alok issues the instruction (Fig 2).	Autonomous — the payment event itself triggers the chain.
Execution	AI-executed. Three systems of record written with no human in between.	Unchanged.
Review	Human, post-hoc. Report read after the fact.	Exception-based only.
Guest communication	Human (and in this run, not done — Finding 6).	Autonomous — direct confirmation to the guest.

So: AI-executed within an AI-assisted workflow. The task is autonomous; the workflow is not. This distinction matters for the ROI arithmetic — the saving today is not a whole task removed, it is the body of a task removed while the initiation and closure remain human. It also matters for the failure mode: an AI-executed error is caught only if someone reads the report, and only if the report mentions it (Findings 7 and 10).

The project is under active development. Autonomy is gated on demonstrated predictability and resilience, not on a date.

On-premise vs cloud

Hybrid — and the distinction matters more than the label.

Layer	Where it runs	What it holds
Harness — orchestration, tool access, credentials, WhatsApp and email read paths	On-premise. 2 vCPU / 2 GB RAM VM inside the Le Mod Casa Harness.	The keys to every connected system
Model — inference (Opus 4.8)	Cloud. Accessed via API / MCP server.	Whatever is in the prompt at inference time
Casa Admin App and data — guest master, reservations, ledger	Cloud. Supabase.	Guest PII, ID documents, payment references, financial records

The decisive factor was control of the harness, not data residency — and those are different things, which is the honest point this field exists to force.

What it bought. Credentials to WhatsApp, email and Supabase are held on infrastructure Le Mod Casa owns, not deposited with a third-party agent platform. There is no vendor orchestration layer between the agent and the systems of record, so the tool surface, the permissions and the execution path are locally defined and locally changeable. Vendor lock-in at the harness layer is avoided; the model behind the API can be swapped without rebuilding the agent — which, given that ~$800 of learning is embedded in skills rather than weights, is a substantial asset (field 4).

What it cost. The VM is Le Mod Casa's to run — uptime, patching, restart and failure recovery are owned, not purchased. For a case whose objective is resilience, that is the material trade: resilience becomes a property the operator must build rather than one a vendor warrants.

What it did not buy — state this plainly. An on-prem harness is not data sovereignty. Guest PII traverses a cloud model API at inference time and rests in a cloud database at Supabase. Anyone reading this case for residency or sovereignty reasons should not copy the "on-prem" label and assume the property. The harness is on-prem; the data path is not.

Training and adaptation method

Prompt-engineered / instruction-configured, with retrieval against live enterprise systems via MCP, and capability captured as versioned skills. No fine-tuning; no custom training. Capability came from tool access, role configuration and an extended skill-acquisition phase — not from model weights.

What was tried first and revised — the most useful sentence in this case. The initial approach put the whole chain through the model. It was progressively split into AI and automation: deterministic steps were extracted into scripts, and the model retained only the parts requiring judgement — reading an unstructured thread, matching a claim to a credit, weighing a rate variance.

That split is the central engineering lesson, and it has two payoffs. Reliability, because a deterministic step cannot be reasoned about differently on the next run. And cost, because every step moved out of the model is tokens permanently removed from every future call. Anyone reproducing this should expect the split to be discovered, not designed — the boundary becomes visible only once the all-model version is running.

The distinguishing fact of this deployment: Jeni De is the first apeople at Le Mod Casa to have been onboarded by another apeople. The staffing of a digital worker was itself performed by a digital worker. In EAIS-03 terms, the gates were run by an actor rather than on an actor by a human — which is the recursive step the framework anticipates, executed in practice rather than in theory.

Pilot — the onboarding phase

The expensive part of this project was not running it. It was creating the worker, and it broke into two components:

(a) Onboarding Jeni — establishing her as a role-holding actor, performed by another apeople.

(b) Teaching the skills and telling the organization — the two are distinct and both were required. Skills are what she can do; the organization is what she must know — Le Mod Casa's properties, units, rate structures, guests, conventions and the shape of its systems. A capable agent with no organizational knowledge produces confident, wrong work.

Together these consumed an estimated 200 million tokens, across four activities:

Activity	What it produced
Skill adaptation	Generic capability shaped to Le Mod Casa's actual systems and conventions
AI / automation split	Deterministic steps extracted into scripts; the model retained only judgement steps
Skill Repository conversion	Skills converted to shareable, versioned artifacts on an existing platform (platform detail out of scope for this case)
Test-case runs and re-runs	Iterative execution against test cases until the reliability demonstrated here was reached

That fourth activity is the fitness evaluation (field 13) — not a vendor benchmark, but repeated trial runs of the actual job until behaviour stabilised.

Scale-up

Not yet attempted at volume. One documented production run. The path to scale is not more capability — it is the confidence threshold for autonomy (field 3).

Change management

Not applicable at this scale — operator, reviewer and owner are the same person. This is the case's principal limitation as a replicable example: it has never survived contact with a second user.

Governance

The operational scaffolding pre-existed the run — a ticket schema with an AI Agent Task category and a handler field, a guest master with stable IDs, a ledger with a reference field. The agent-specific governance layer — the identity stack and the skill registry — exists but is not documented in this case; see Annexures A and B. See field 13 for the gate-by-gate assessment.

Observed in one run. Not a scaled claim.

• Chain completeness — the transaction chain that most often fragments (identity → reservation → payment proof → ledger → audit) completed as one unit, verified across Figures 3, 4 and 5.
• Quality of verification — the payment was proved against the bank credit. More rigorous than the manual process it replaced, where a screenshot was routinely accepted on trust.
• Revenue protection — the ₹2,699 / ₹2,500 rate variance was surfaced to the handler. Manually it would have passed unremarked. (Though not recorded — Finding 10.)
• Guest recognition — the returning guest resolved to an existing master record with ID documents already on file, rather than being re-entered as new.
• Auditability — a High-priority ticket exists, correctly categorised, with a complete narrative trail and a named handler. The month-end reconstruction problem is solved.
• Transferable capability — because capability lives in versioned skills rather than model weights, the ~$800 of learning is portable across models and reusable across future apeople (field 9).
• Employee experience — the interrupt is removed. The owner is no longer the reconciliation engine.

The objective is resilience, not saving. Success is measured by whether every step a reservation requires actually completed, and whether the resulting records agree with one another. Cost is a constraint here, not a benefit.

Primary KPI — chain completion audit

Seventeen steps a complete reservation requires, scored against the five artifacts:

#	Step	Status	Evidence
1	Guest resolved to master record	✅	Guest [guest id], Figs 3, 4, 5
2	Past-guest status confirmed, history retrieved	✅	Figs 3, 5
3	Rate determined	✅ variance flagged to handler	Fig 3
4	Reservation record created — unit, dates, nights, occupancy	✅	Figs 4, 5
5	Confirmation code issued	✅ [confirmation code redacted]	Figs 3, 5
6	Reservation status set	✅ Confirmed → Payment Received	Figs 3, 5
7	Payment claim located	✅	Figs 3, 5
8	Matching credit located	✅ pay_[redacted]	Figs 3, 5
9	Claim and credit proved to be the same event	⚠️ soft join	Finding 1
10	Finance ledger row posted with reference	✅ g8_ac_txn, txn [txn redacted]	Figs 3, 5
11	Ticket opened, categorised, handler named	✅ #2586, AI Agent Task, handler=Alok	Fig 5
12	Ticket closed with full trail	✅ self-closed	Fig 5, Finding 3
13	Human report returned with declared uncertainty	✅	Fig 3
14	Guest ID documents on file	✅ inherited from master	Fig 4
15	Check-in / check-out times set	❌ "Not set"	Fig 4
16	Confirmation sent to the guest	❌ not sent (scoped for autonomy phase)	Figs 1, 5
17	Inventory blocked on distribution channel (Lodgify)	❓ unverified	Fig 4 toolbar

Score: 13 complete · 1 soft · 2 not done · 1 unverified.

The honest reading: the transaction chain completed; the reservation record did not. Everything Jeni was asked to do, she did, and two systems of record confirm it. Everything a reservation also requires — a guest who knows their confirmation code, times set, inventory blocked downstream — was neither done nor flagged. Under a completeness objective, that is the result, and it is more useful than the thirteen ticks.

Secondary — timing and resilience

Measure	This run	Status
Instruction → booking complete in 3 systems	2 min 10 s (18:45:54 → 18:48:04)	Observed
Guest payment → confirmed reservation	~10 min (18:38 → 18:48:04)	Observed
Records in agreement across systems (Figs 3 / 4 / 5)	Yes on all shared fields	Observed
Orphaned records created	0	Observed
Variances surfaced to the handler	1 of 1 known	Observed
Variances recorded in the permanent record	0 of 1	Observed — Finding 10
Gaps surfaced vs gaps present	1 of 4 — steps 9, 15, 16, 17	Observed — the weak result
Recovery behaviour on partial failure	Never tested in production	Finding 9
Chain completion rate over N production runs	[to capture]	n=1

SLA / target definition — open. No target was set on this ticket (Fig 5), so the 2 min 10 s has nothing to be measured against. Definition of the SLA and the KPI thresholds is outstanding and should be settled before the next run — see the note at the close of this document.

Cost of the AI project

The dominant challenge, and reported here in full because TPL-B is right that the pilot-to-production relationship is the most useful number in any AI case study.

What it cost to build.

Component	Figure
Setup tokens (skill adaptation, AI/automation split, Skill Repository conversion, test-case runs)	~200,000,000
Setup cost (Opus 4.8)	~US$800

What it costs to run.

Component	Figure
Tokens per call	250,000 – 500,000
Cost per call	~US$2.00
Harness (2 vCPU / 2 GB RAM VM)	Nominal, standing

The pilot-to-production analysis — and why this case inverts the usual pattern.

TPL-B warns that pilots are cheap because they are small, and that many AI projects are killed not by failure but by working. That warning does not bite here, and it is worth understanding why. The expensive component was one-time learning, not per-transaction inference. Setup does not recur; the marginal cost is flat and known.

Cumulative bookings	All-in cost per booking
1	~$802
50	~$18
200	~$6
500	~$3.60
1,000	~$2.80
→ ∞	→ $2.00

The economics improve with adoption rather than degrading. That is the opposite of the consumption-scaling trap, and it is a direct consequence of the AI/automation split (field 3): capability that was moved into scripts costs nothing per call, forever.

Three cautions against reading this too favourably.

One — the per-call cost is material against the transaction value. At roughly ₹170–180, US$2.00 is about 6–7% of this ₹2,500 room night. That is not negligible for a hospitality operator, and it is the correct comparison — not "$2 is cheap," but "$2 against what the booking is worth." Lower-value transactions may not carry it.

Two — the autonomous version has different economics, and they are not yet known. Everything above is invoke-on-instruction: one call, one booking, cost coupled to revenue. The target state watches channels continuously, which decouples calls from bookings — the agent spends tokens on quiet evenings too. This is precisely where TPL-B's warning applies, and it is the number that must be metered before autonomy is switched on.

Three — 250–500k tokens per call is high for this task, which means headroom exists. Most of that is context, not reasoning. Further AI/automation splitting is the lever, and it has already been proven to work once.

Cost of stopping halfway. Not applicable — the deployment is single-track, not a partial migration.

Adoption barriers

None encountered — the sole user is the person who commissioned it. Absence of evidence, not evidence of low friction.

Data quality

The run succeeded because the underlying records were clean: a stable guest ID, a gateway emitting a per-transaction identifier, a ledger with a reference field, a ticket schema with category and handler fields. Reconciliation is only possible where identifiers already exist. An operator without them must build them first.

Change resistance

Not encountered at this scale. Expected to become live at the autonomy transition, where the change is not "an assistant helps" but "no one is asked."

Security concerns

Live and material. The harness reads a personal WhatsApp account and a Gmail inbox, and reads/writes a guest PII master holding national ID documents (Figure 4). Guest PII crosses a cloud model API at inference and rests in Supabase. Permissions scope, credential handling, retention and the off-switch are governed under Annexure A. The personal-WhatsApp read path carries platform risk of its own: there is no sanctioned API for personal WhatsApp, and automating it puts the number at risk.

Finding 1 — the claim-to-credit join is soft

Two legs, unequal strength:

Leg	Key used	Strength
Credit → ledger	pay_[redacted] → txn_ref	Hard. Unique gateway identifier.
Claim → credit	Amount + timestamp proximity + payee	Soft. Probabilistic.

The guest's screenshot carries no UTR and no gateway ID — nothing that also appears in the Razorpay notification. Jeni's own words in the ticket confirm the method: "matched WA screenshot + Gmail confirmation." The join was ₹2,500 matching ₹2,500, ten seconds apart, same payee.

At this volume that is fine and will be right almost always. It is not a proof, and it will not survive collision — two guests paying an identical amount inside the same window is not exotic in hospitality, where prices repeat by design.

The fix is not a better matcher. It is to take the screenshot off the critical path: the gateway notification alone authorises; the screenshot is a courtesy with no evidential weight. This matters more at autonomy, where no human sees the match before it commits.

Finding 2 — the human checkpoint sits after execution

The reservation was created, the ledger row posted and the ticket closed before the rate variance reached a human. At ₹199 on one booking that is immaterial. As a pattern it changes what a correction costs: a pre-execution flag is a question; a post-execution flag is a reversal — amend the reservation, adjust the finance row, reopen a closed ticket. Figure 5 shows the Reopen button, so the mechanism exists; the point is that it should not routinely be needed.

This is the right model for delegated execution, and the run proves it works in 2 minutes 10 seconds. But it needs guardrails rather than defaults — a value threshold above which nothing commits, and a rule that a flagged variance holds the finance row rather than posting it. Both become load-bearing at autonomy.

Finding 3 — the agent opened, updated and closed its own ticket

Assigned To: Jenni De. Update #6669 by Jenni De. Update #6670, action close, by Jenni De. Completed 18:48:04 by Jenni De. The agent is author, actor, assignee and closer of its own audit record.

The trail is genuinely good. The review trail does not exist. A closed ticket normally signals that someone checked; here it signals only that the agent believes it finished — and Figures 4 and 5 both show it had not (Findings 7, 10, 15/16 in the completion audit).

Small fix, real value: agent-executed tickets resolve to pending review and close on a human action. Given that the platform already has AI Agent Task as a category, this is a workflow rule on an existing field, not new infrastructure. It converts the queue from a log into a supervision mechanism — and at autonomy it becomes the primary supervision mechanism, since there will be no chat report to read.

Finding 4 — the claim/authorisation distinction held

The screenshot was treated as a claim. The Razorpay credit was treated as the authorisation. Jeni did not book on the picture.

This is the most valuable behaviour the run demonstrates, because screenshot-based payment fraud is the dominant risk in exactly this workflow across Indian hospitality and retail.

One question remains, and it is now answerable rather than open. Whether the behaviour is enforced — a hard constraint in Constitution.md — or emergent from instruction and model capability determines whether it survives a marginal case. Annexure A holds the answer; stating it explicitly in that annexure is what converts this from an observed behaviour into a guaranteed one, and it should be settled before autonomy.

Finding 5 — the verbal hold had no system representation

"Done, Will reserve one for you" (Figure 1, 18:30) committed the unit before money moved and existed only as a sentence in a chat thread — roughly fifteen minutes before ticket #2586 opened. For a single property this is survivable. Across units it is a double-booking waiting to happen, and the failure stays invisible until two guests arrive.

At autonomy this closes naturally: the agent that reads the thread can place the hold at the moment of promise.

Finding 6 — the guest was never sent a confirmation

Figures 3 and 5 both record that confirmation code [confirmation code redacted] was issued. Figure 1 shows the thread ended at "Thanks." The code exists in two systems and never reached the person it was for.

Figure 5 makes this sharper: the ticket carries a "Send WhatsApp" action, sitting unused at the top of the very record containing the confirmation code.

This is a scoped gap, not an unflagged one — direct guest confirmation is explicitly part of the autonomy phase. But it remains the live gap today, and the only one the guest experiences: he arrives on 01 August holding a payment screenshot and no booking reference. Until autonomy lands, this step needs a human owner, because at present it has none.

Finding 7 — Figure 4 exposes what the reports did not mention

Check-in Time and Check-out Time both read "Not set." Neither Figure 3 nor Figure 5 mentions them.

A different class of problem from the rate variance, and a worse one. The variance was a known unknown — found, weighed, declared. The unset times are an unflagged gap: the agent's completion model and the record's completion requirements are not the same thing, and nothing in the run detected the difference.

The lesson generalises: an agent reporting "done" is reporting against its own definition of done. Where the system of record has a required-field set, that set — not the agent's judgement — should define completion. This is the strongest argument in the case for verifying against the system of record rather than trusting the report, and it is a prerequisite for autonomy, where no one will be reading the report at all.

Finding 8 — downstream inventory sync is unverified

The Casa Admin toolbar (Figure 4) carries a Lodgify action — the distribution channel. Whether this reservation propagated there, blocking lmc_429 against other booking channels, is not evidenced by any of the five artifacts, and the ticket close note does not mention it.

If it did not, the unit remains sellable elsewhere for a night that is already paid for, and the failure surfaces as a double-booking on arrival. Verify before the next run — this belongs in the required-step set.

Finding 9 — the failure path is proven in test but not in production

The stated objective is a resilient system, and resilience was pursued deliberately: the test-case runs and re-runs during onboarding (field 4) are what produced the current reliability level.

What remains untested is production failure behaviour — reservation created and the Supabase write times out; ledger posted and ticket creation fails; model API unavailable mid-chain. Test-case reliability establishes that the chain works repeatedly; it does not establish what a half-completed chain does when a real dependency drops.

Deliberate fault injection against the live stack — kill the connection between step 4 and step 10 and observe whether the chain rolls back, resumes, or silently half-completes — is the remaining resilience test, and it is the one that should gate autonomy.

Finding 10 — the one judgement call in the run is absent from the permanent record

Figure 3 (to Alok, in chat): "the unit's listed nightly rate is ₹2,699, but I used ₹2,500 to match what was actually quoted/paid… If ₹2,500 wasn't the intended rate this time, let me know."

Figure 5 (ticket #2586, the permanent record): no mention of the rate at all. The close note records ₹2,500 as fact, with no indication that it differs from the listed rate or that a decision was made.

The variance went to the ephemeral channel; the record got the outcome without the reasoning. Anyone auditing ticket #2586 in six months sees a clean ₹2,500 booking and no sign that judgement was exercised.

This is the most instructive finding in the case, because it is so easy to miss: the agent behaved well — it surfaced the variance, it asked, it deferred — and the governance still failed, because it surfaced to a person rather than to the record. Flagging and recording are different acts, and only one survives.

It is also the finding that matters most for autonomy. When there is no human to message, the record is the only place uncertainty can land. An agent that flags to chat and not to the record is safe today and silent tomorrow.

Rule: anything the agent flags as uncertain goes into the permanent record before it goes anywhere else.

Finding 11 — proprietary terminology appears in a non-canonical variant in a production system

Ticket #2586's brief reads: "Jenni-De (Aperson, EA, handler=Alok)."

Two departures from the canonical vocabulary, both now written into a production record:

• "Aperson" is not the coined term. The taxonomy is xpeople / hpeople / apeople / rpeople / dpeople / mpeople, and the established convention — as with aJD — is a deliberate lowercase prefix. "Aperson" is an ad-hoc singularisation with a capitalised prefix, contradicting the convention on both counts.
• "Jenni-De" / "Jenni De" varies against "Jeni De" elsewhere. The actor's own name is not canonical.

Minor editorially, material here given the pending filing: coined terms derive strength from consistent, distinctive use, and production systems are where usage gets established. Two decisions:

1. What is the singular of apeople? If a singular is needed, decide it, fix the case convention, and add it to the terminology list logged for the IDF. If none is intended, the correct phrasing is "an apeople" and "Aperson" should be corrected wherever it appears.
2. Fix the canonical spelling of the agent's name and apply it in every system.

The term is presumably templated, which means it will keep recurring — worth a sweep of all production systems, not just this ticket.

Finding 12 — an audit update with no content

Update #6669 says "check." One word, no content, timestamped between opening and closing. Whatever it was meant to record, it records nothing a reader can use. Intermediate updates should either carry state or not exist — and at autonomy, intermediate updates are the only visibility into a running chain.

Where the corrections landed

Applying TPL-B's own test honestly:

Correction	Where it landed	Should be
Rate variance (₹2,699 vs ₹2,500)	A chat message. Not in the ticket. Resolved in Alok's head.	A skill: hold the finance row on rate variance; record the variance in the ticket before notifying anyone.
AI / automation split	✅ A skill artifact, in the Skill Repository (Annexure B)	Already correct — the model this case should follow
Soft join key	Nowhere	A skill: authorise on gateway credit only; screenshots carry no evidential weight.
Unset required fields	Nowhere	A skill: validate the created record against the system's required-field set before reporting done.
Guest confirmation not sent	Scoped to the autonomy phase; no owner today	An interim human owner, then a skill.
"Aperson" / name variants	Nowhere	A terminology control enforced in system templates.

One correction from the build phase landed correctly — the AI/automation split, captured as versioned skills. That is the proof that the mechanism works. The corrections from this run have not yet followed it, and they currently exist only as observations in this document.

Replicability of the skills is 100%, conditional on the prerequisites below being available. This is not a hedge — because capability is captured as versioned artifacts in a Skill Repository rather than as model weights or individual expertise, transfer is a copy operation, not a rebuild. This is the practical difference between hpeople and apeople skill acquisition: what a person learns must be taught again; what an apeople learns can be granted.

The prerequisites, all of which must be present:

1. A guest master with stable identifiers. Without it there is no repeat-guest recognition and nothing to reconcile against.
2. A payment gateway emitting per-transaction notifications with a unique ID.
3. A finance ledger with a reference field that can hold that ID.
4. Write access to reservation, ledger and ticket systems. Read-only produces advice, not automation.
5. A defined required-field set for a complete reservation — otherwise "done" means whatever the agent thinks it means (Finding 7).
6. A ticket schema that can classify agent work and name a handler — Le Mod Casa had this before the run, and it is why the run is auditable at all.
7. A Skill Repository capable of holding versioned skills and detecting drift (Annexure B).
8. The identity stack — aJD, Constitution, Soul, User, Memory (Annexure A).
9. A harness with locally held credentials and connectivity to a capable model.

Requirements 1–3 are the real barrier for most operators, and they are not an AI problem — they are a systems-of-record problem, to be solved first. Requirement 6 is the cheapest and most overlooked: two fields on an existing ticket schema.

On cost transfer. The ~$800 setup is not incurred again per deployment where the Skill Repository is shared — that is the point of holding capability as artifacts. A second property, or a second apeople in the same role, inherits the skills. What does not transfer is organizational knowledge: a different operator's properties, rates, guests and conventions must still be told.

Skills to contribute

Four candidates, each with the envelope TPL-B requires:

Skill A — Three-way payment reconciliation (claim / credit / ledger). Provenance: onboarding test-case phase, proven in production 30 Jul 2026. Proven under: single currency (INR), single gateway, UPI, one payment per booking, low volume. Not tested beyond: multiple gateways, partial or split payments, refunds, foreign currency, concurrent identical amounts, live dependency failure. Known limitation: the claim-to-credit leg is soft where the claim carries no reference (Finding 1). Version: 0.1.

Skill B — Repeat-guest resolution and rate surfacing. Provenance: as above. Proven under: verified mobile as primary key, single prior stay, single property. Not tested beyond: guests with multiple numbers, duplicate master records, corporate or group bookings. Known limitation: prior rate was applied and then flagged to a person, not recorded (Findings 2, 10). Version: 0.1.

Skill C — Completion validation against the system of record. Status: does not yet exist. Identified by Figure 4. Arguably the most transferable skill in the case, because every agent writing to a system of record has the Finding 7 problem — and it is a hard prerequisite for autonomy.

Skill D — Record-before-notify. Status: does not yet exist. Identified by Figure 5. Any uncertainty the agent declares must land in the permanent record before it lands anywhere else. Equally transferable, and equally invisible until something needs auditing (Finding 10).

A skill adopted outside the envelope it was tested in is a liability, not an asset. Skills A and B carry an envelope of extensive test-case runs plus one production transaction, on the happy path.

Gate to autonomy. The following are prerequisites, not preferences — each closes a gap that a human currently absorbs and no one will absorb at autonomy.

1. Record-before-notify (Skill D) — at autonomy the record is the only place uncertainty can land (Finding 10).
2. Completion validation against the required-field set (Skill C), including check-in/out times (Finding 7).
3. Direct guest confirmation as a mandatory chain step — the "Send WhatsApp" action already exists (Finding 6). Assign an interim human owner until then.
4. Rate-variance hold — flagged variances hold the finance row rather than posting it (Finding 2).
5. Pending-review resolution on agent tickets — a workflow rule on the existing AI Agent Task category (Finding 3).
6. Production fault injection — the remaining resilience test (Finding 9).
7. Meter the always-on economics before switching the trigger (field 7). This is the number most likely to surprise.
8. State the claim/authorisation rule explicitly in Constitution.md (Finding 4, Annexure A).

Near term. 9. Verify Lodgify propagation and add it to the required-step set (Finding 8). 10. Represent the verbal hold in Casa Admin, time-bound (Finding 5). 11. Correct "Aperson" and canonicalise the agent's name across production systems; log for the IDF (Finding 11). 12. Set SLA targets and KPI thresholds so timing has a standard (field 6). 13. Move guest payment traffic to WABA; retire personal-WhatsApp from the critical path. 14. Further AI/automation splitting to reduce the 250–500k tokens per call (field 7). 15. Attach Annexures A and B.

Then. 16. Second property / second apeople — test the 100% skill-transfer claim in practice (field 9). 17. Full identity-stack assembly against EAIS-03's eight gates.

Where the organization stood. A human performing manual, interrupt-driven reconciliation across three surfaces, with payment claims frequently accepted on trust and chain steps routinely left half-done. But — importantly — the operational scaffolding was already in place: a ticket system with an AI Agent Task category and a handler field, a guest master with stable IDs, a ledger with a reference field.

Where this initiative took it. An apeople executing a cross-system transaction end-to-end on a natural-language instruction in 2 minutes 10 seconds, writing to three systems of record, verified independently in two of them — and staffed by another apeople.

That last clause is the significant one. An organization in which digital workers onboard digital workers is operating at a materially different level from one in which humans configure tools, and it is the specific condition EAIS-01's upper stages describe. The task here is delegated execution; the organizational capability demonstrated is a step beyond it.

Precise stage numbers to confirm against the EAIS-01 stage definitions — provisionally Stage IV for the task, higher for the staffing capability. [to confirm]

What had to be true first. Stable guest identifiers, a gateway emitting per-transaction IDs, a ledger with a reference field, a ticket schema able to classify agent work and name a handler, write access across all of them, a Skill Repository, and a harness with locally held credentials. The capability was unlocked by the record-keeping, not by the model. Any organization reading this case should test itself against that sentence before testing itself against anything else here.

An apeople. Jeni De held the role. The organization's own systems say so: ticket #2586 is categorised AI Agent Task, assigned to Jenni De, with handler=Alok.

The line — tool or actor? An actor. The test is not sophistication but authority: Jeni wrote to the reservation system, the finance ledger and the ticket queue with no human intermediary, and Figures 4 and 5 confirm the writes are real. A tool would have produced a draft for a person to enter. She entered it, and then closed her own ticket about it.

And the role was conferred by another actor. Jeni was onboarded by another apeople — so the answer to "who held the role" has a recursive edge: an apeople held the operational role, and an apeople held the staffing role that created it.

Assessed against EAIS-03's gates. The detailed governance instruments are held in Annexure A (identity stack) and Annexure B (Skill Registry); this table assesses status, and the annexures carry the substance.

Gate	Status	Detail
Role definition	⚠️ Partial — pending Annexure A	The role is declared in the operational record: ticket #2586 names the actor, its class, its function (EA) and its handler. The aJD exists and is governed under Annexure A; it is not reproduced in this case, so a reader cannot yet assess it.
Governing principles	⚠️ Partial — pending Annexure A	Constitution.md governs enforced constraints. The specific question this case raises is whether the claim/authorisation rule (Finding 4) is stated there as a hard constraint. Annexure A should answer it explicitly — it is the single most consequential line in the governance layer.
Fitness evaluation	✅ Done (corrected)	Not a vendor benchmark — repeated trial runs of the actual job, re-run against test cases until reliability stabilised, during the onboarding phase (field 4). This is precisely what the gate asks for. Strengthening step: record the pass criteria and results as an artifact, so the evaluation is auditable rather than asserted.
Onboarding	⚠️ Partial — pending Annexure A	Identity established in the ticket system (named assignee, handler). Least-privilege scoping, consumption budget and off-switch are governed under Annexure A. The off-switch should be tested and the test recorded — on an on-prem harness this is entirely within Le Mod Casa's power.
Organizational induction	✅ Done	Deliberately performed — a distinct workstream in the build ("telling" Le Mod Casa's properties, units, rates, guests and conventions), separate from skill acquisition. Evidenced in the run: she knew the listed rate was ₹2,699 rather than inferring it. The strongest governance result in the case, and the one most operators skip.
Operation	⚠️ Partial	A named accountable human is in the record itself — handler=Alok. Agent work is a queryable category. Both real assets. But supervision is post-hoc review of a report; Finding 7 shows the report misses things and Finding 10 shows the record does too; and the agent closes its own tickets (Finding 3). At autonomy the report disappears, so these must be closed first.
Skill drift	⚠️ Governed — pending Annexure B	A Skill Registry manages drift across versioned skills. This is a governance instrument most deployments lack entirely, and it is the mechanism by which the corrections in field 8 should be captured.
Exit	❌ Not done	No retirement path declared. Jeni runs indefinitely.

Governance summary. Three gates passed, four partial pending annexures, one not done.

The shape of this assessment is worth naming. The governance infrastructure was built before the run — agent-task classification, named handler, a skill registry with drift management, an identity stack, a fitness evaluation regime. What is missing is not plumbing but a small number of rules running on it: pending-review instead of self-close, a required-field check before "done", record-before-notify, a declared exit path.

Those are configuration decisions on systems already owned, not a build — and every one of them is on the critical path to autonomy, because each currently depends on a human noticing something.

---

---

Annexure A — The Identity Stack [to be attached]

The governance layer under which Jeni De operates. Not visible in the run artifacts and therefore not assessable from this case alone.

File	What it should establish for this case
aJD	The declared role, scope and boundaries of the reservation and reconciliation function
Constitution.md	Hard, non-field-mutable constraints. Must state explicitly whether "a payment claim never authorises a booking" is an enforced rule (Finding 4).
Soul.md	Voice and conduct on guest-facing channels — load-bearing once direct guest confirmation is automated (Finding 6)
User.md	Who may instruct, who may override, who receives exceptions — and who receives them when no human is in the loop
Memory.md	Guest history, prior rates, recurring payers, resolved exceptions; the accretion policy and its retention rule

Because these are live reference files, changing any of them changes behaviour at runtime: document change control is fleet change control.

Annexure B — The Skill Registry and drift management [to be attached]

The mechanism by which capability is held, versioned, granted and monitored for drift — and the reason replicability is 100% (field 9).

Should cover: registry structure and versioning; how skills were converted from the build phase; the drift-detection method and its cadence; the response when drift is found; the skill envelope record (provenance, proven-under conditions, boundaries, limitations); and the grant model for a second apeople or a second property.

---

---

In this document	Replace with
[Guest name withheld]	Guest A
+91 XXXXX XXXXX / +91XXXXXXXXXX	[mobile redacted]
Guest ID [guest id], g8_prop_id 28	[redacted]
pay_[redacted], ledger txn [txn redacted]	[redacted]
[confirmation code redacted], res #3533, ticket #2586, updates #6669/#6670	[internal reference redacted]
Cost figures	Retain — they are the most valuable content in the case for an external reader
Figure 1	Contact name and avatar legible in header — redact or re-shoot
Figure 2	Redact the mobile number
Figure 3	Redact guest name and guest ID
Figure 4	⚠️ Highest sensitivity. Guest name (twice), mobile (twice), and a national ID document image. The ID thumbnail must be removed entirely, not blurred.
Figure 5	Redact guest name (title and brief), mobile, guest ID, property ID, payment ID. The brief is prose and needs careful masking rather than a box over a field.

For any FICCI submission, the recommended route is to re-run the flow on synthetic guest data and capture fresh figures. The findings transfer; the PII does not have to — and Figures 4 and 5 should not leave the building in their current form.

---

---

Held in figures/ alongside this file. Re-upload these if the workspace resets — they cannot be reconstructed.

Figure	File	Shows
1	figures/fig1_whatsapp-guest-thread.png	Guest exchange, verbal hold, QR, payment claim
2	figures/fig2_instruction-to-jeni.png	The natural-language instruction
3	figures/fig3_jeni-response-reconciliation.png	Execution, reconciliation, rate flag — reported to the handler
4	figures/fig4_casa-admin-reservation-verification.png	The reservation verified in Casa Admin — and the unset fields
5	figures/fig5_ticket-2586-audit-trail.png	The audit record — timings, self-close, and what the record omits

---

---

Item	Owner	Note
SLA / KPI definition	—	Outstanding. No target was set on ticket #2586, so the 2 min 10 s has no standard to be measured against. Thresholds needed for: instruction-to-completion, payment-to-confirmation, chain completion rate, exception rate, and cost per booking.
Annexure A — identity stack	—	To be attached
Annexure B — Skill Registry	—	To be attached
Singular of apeople; canonical agent name	—	Finding 11; log for the IDF
EAIS-01 stage numbers	—	Field 11, provisional
Always-on cost metering	—	Field 7; gates autonomy

---