4 posts tagged with "Agentic systems"

Ferrowick is a fictional construction-operations platform used by mid-sized building contractors. Customers run whole projects on it: purchase orders, delivery receipting, retention tracking, subcontractor valuations, and the weekly supplier payment run. Ferrowick holds no customer money; payments are initiated through Norwell Pay, a fictional licensed payment provider that submits into a bank scheme.

Kelter is Ferrowick's realtime site assistant, and it exists because of one physical fact. The person who knows what actually arrived is standing in a delivery bay in gloves and hearing protection, beside a reversing lorry, with a clipboard in one hand. She is not going to open a laptop. Kelter runs on a site handset or a paired headset, connects over WebRTC to a regional media edge, listens, and speaks.

A payment passes three decisions, made by different people at different times. On Monday the project manager approves the week's run in the web application, deciding what may be paid at all. During the week the site operations lead receipts deliveries, deciding what arrived. When retention conditions are met she releases the matching payment by voice, deciding what is sent now and in what order.

That third decision matters, because a project's available balance is finite and sequenced. Releasing early does not move money to the wrong week; it consumes the headroom a later payment depends on. A supplier who is not paid does not deliver, and a crew that arrives to an empty bay stands idle at full cost.

Priya Raghavan is Site Operations Lead on the fictional Halden Row project; she receipts deliveries and releases approved payments. Tomas Idrissi is a Staff Engineer who owns Ferrowick's realtime interaction plane — media session, connection epoch, turn state, playout, interruption handling. Dela Okonkwo is a Principal Engineer who owns the payment-effect plane — the gateway, the operation ledger, the Norwell Pay integration. Ruth Vance is Head of Payment Operations, and owns what a customer is told when the state of a payment is uncertain.

Tomas and Dela both built correct systems. The sentence that caused this incident lived in Tomas's plane and was about Dela's, and nobody had ever decided which of them owned it.

Harborlight People is a fictional workforce-management SaaS company. Its employer customers use the platform for payroll, scheduling, employee relations, support, and access administration. They can also configure a workflow through which current and former workers request copies of their personal data.

The employer customer defines the request policy, the source categories in scope, and who may make the final release decision. Harborlight operates the software and a managed privacy-operations team under that customer-defined policy. The process in this story is Harborlight's fictional design, not a universal legal requirement.

Harborlight handled about 3,800 worker-data requests per month. Most looked simple from the request portal: prove who you are, describe the employment period, wait while the records are assembled, and collect a package from an authenticated portal.

The work behind that path was not a single database query.

A worker might have a legal name, a preferred name, a former surname, several email addresses, and more than one worker identifier after a rehire or contractor conversion. A support ticket might mention a person without being about that person. An attachment might be linked to a ticket whose requester and uploader were neither its subject. A fixed join could recover the obvious records. It could not reliably resolve every free-text reference, copied attachment, or derived record.

That was why Harborlight built Lumen, a bounded AI privacy worker. Lumen read case-scoped records through narrow adapters, resolved aliases and free-text references, proposed which records concerned the requester, explained the evidence behind each proposal, and suggested redactions. Lumen could produce candidates. It did not own a person's stable identity, record-subject truth, case policy, approval, delivery credential, or the release of bytes.

Mara Chen, the Senior Privacy Operations Specialist responsible for defining request scope and resolving ambiguous record matches, supervised the managed workflow. Under each employer's policy, she could approve an exact release.

The distinction sounded conservative enough: Lumen proposed; Harborlight decided.

Northstar Ledger (a fictional B2B commerce-infrastructure company) routes checkout and inventory updates for regional grocery chains. Its customers do not run one Northstar checkout page. They use Northstar behind their own mobile apps, self-checkout kiosks, and delivery sites.

At the Saturday peak, those systems send roughly 48,000 order operations per minute. A short outage creates queues. An incorrect recovery can create something worse: orders accepted through a path that the company no longer believes is authoritative.

Northstar stored checkout state in an Amazon Aurora PostgreSQL global database. The primary Region served writes. A secondary Region stayed ready for disaster recovery. The operating rule was strict: Northstar could advertise only the writer confirmed by Aurora's current topology.

Imani (the Staff Reliability Engineer responsible for Northstar's database-recovery control plane) had spent the previous six months reducing the time between an incident page and a safe recovery decision.

Her team built Relay, a bounded AI incident worker. Relay read approved telemetry, compared an incident with reviewed runbooks, and proposed a typed recovery plan. It could not promote a database or change traffic. A deterministic policy service checked every proposal. A human incident commander then approved the exact target and the maximum tolerated data loss before any effect was allowed.

This mattered because Relay was useful precisely where incidents were messy. It could gather replication lag, recent deployments, health probes, and runbook constraints in seconds. It could explain why one recovery target fitted the evidence better than another.

It could not make an ambiguous cloud operation unambiguous by thinking harder.

Kiteframe Pay (a fictional payment-risk infrastructure company) helps online marketplaces decide whether a card order should be approved, declined, or reviewed by a human. Merchants call Kiteframe during checkout, before they capture money or promise inventory to a shopper.

Most orders never need generative AI. Deterministic rules settle obvious cases in under 80 milliseconds. The difficult eight percent—new devices, unusual delivery patterns, sparse account histories—enter Aster, Kiteframe's AI-assisted risk analyst.

Aster was not a chatbot and could not approve a payment. It gathered approved evidence, used a language model to produce a typed risk recommendation with cited signals, and passed that recommendation to a deterministic merchant-policy engine. Without Aster, those ambiguous orders went to a manual-review queue. During a large sale, that queue could grow faster than Kiteframe's analysts could empty it.

At 02:13 on Tuesday, model latency rose sharply. Seven minutes later, Kiteframe's entire checkout success rate had fallen from 99.4% to 71%.

The model provider was recovering.

Kiteframe's retries would not let it.