DEV Community: Lohith Lalesh

Building a warehouse training scenario: when is it a digital twin?

Lohith Lalesh — Sat, 07 Nov 2026 19:01:49 +0000

A detailed 3D warehouse is not automatically a digital twin. For training, the first useful version may be a simulation with accurate routes, equipment clearances, task order and hazards. It becomes a digital twin when the training model is connected to a defined real-world facility, kept current from trusted data, and used to inspect or rehearse changes in that facility.

That distinction affects cost and design. A safety lesson may not need live sensor feeds. A facility planner testing a new picking route may need a current layout, equipment positions and movement data. Decide what decision the model must support before asking for full fidelity.

Start with one teachable decision

Suppose new warehouse staff must respond to a blocked forklift route. The learner should identify the obstruction, stop at the correct point, choose a safe alternate route, alert the right person and document the exception. That is a better brief than “make an immersive warehouse.” Write the expected action and the unsafe alternatives first. Then determine what the learner must see, hear and interact with.

Map the real process with warehouse supervisors and HSE staff. Capture the route, pedestrian crossings, visibility limits, signage, equipment speed assumptions and escalation rules. Use photographs, floor plans or BIM where available, but verify dimensions and current operating practice on site. A visually impressive scene with the wrong stopping distance teaches the wrong behaviour.

Build the smallest interactive model

Represent the environment as reusable zones, racks, vehicles, people and hazard states. In a VR implementation, interactors and interactables can handle selecting an object, using controls and moving through the scene; Unity's XR Interaction Toolkit provides those primitives. Keep the scenario logic separate from the visual model so trainers can change a route or hazard without rebuilding the entire experience.

A basic scenario needs: a trigger, observable cues, choices, consequences, feedback and a reset. Record which cue was noticed, what action was chosen, the response time, and whether the learner followed the correct escalation path. Keep assessment criteria visible to instructors and give trainees a chance to practise again. Do not equate headset time with competence.

Add a live data connection only for a reason

A digital-twin layer may pull approved layout revisions, asset status or simulated operational data from a warehouse system. Identify the authoritative source and refresh interval for each feed. Label data as live, delayed, synthetic or manually maintained. A stale route rendered as current is more dangerous than a plainly labelled training scenario.

A sensible first pilot compares one training module with the current method. Look for missed hazards, wrong route choices, instructor corrections, time to complete the task and trainee feedback. Do not claim injury reduction from a short pilot; that would require a much stronger evaluation.

I work at OneBonsAI Gulf. For teams deciding between a simulation and a connected facility model, our digital twins and simulation service explains the scope.

Further reading: Unity XR Interaction Toolkit and AWS IoT TwinMaker overview.

Syncing CRM and ERP data through one API layer

Lohith Lalesh — Sat, 07 Nov 2026 18:53:57 +0000

A CRM and an ERP rarely mean the same thing by “customer.” The CRM may own the relationship and sales pipeline; the ERP may own billing identity, tax details, credit limits and invoices. A single API layer helps when it makes those ownership rules explicit. A gateway alone does not solve inconsistent data.

Decide which system owns each field

Write a field map before writing code. For every identifier, name, address, tax number, payment term and status, record the owner, allowed editors, validation rule and conflict rule. Give each customer a stable cross-system ID. Do not assume that matching on company name or email will remain reliable after a rename, merger or duplicate import.

Example: a salesperson changes the trading name in the CRM. The integration can update the ERP display name, but it should not silently overwrite a verified legal name or tax registration. That difference belongs in the contract of the API, not in an exception buried in a script.

Use a narrow domain API

Expose operations such as createCustomerDraft, approveBillingIdentity, syncContact and getInvoiceStatus. Avoid exposing every ERP table and every CRM object through a generic proxy. The API layer should translate each system's payload into a stable domain model, validate it, apply authorisation, and record the outcome. Keep adapters for the CRM and ERP behind that contract so either vendor can change without forcing every caller to change.

For writes, choose whether the call is synchronous or queued. A queued integration can return a tracking ID while the ERP processes the change. The caller can then check pending, applied or failed rather than assuming a successful HTTP response means the ERP record exists.

Design for retries and conflicts

Networks fail. Webhooks can arrive twice or out of order. Give every business event an immutable ID and every write an idempotency key. Store the last accepted version from each system. If the same event arrives again, return the prior result; if an older version arrives, reject or quarantine it. Do not use “last write wins” for credit limits, bank details or legal identity.

Keep a dead-letter queue with a named owner. Log the source record ID, destination record ID, operation, timestamp, validation errors and retry count, while limiting sensitive data in logs. Build a reconciliation report that compares important fields across both systems daily. Monitoring only API uptime will miss semantic failures such as a customer mapped to the wrong account.

Roll out one object at a time

Start with one direction and one object, such as approved CRM opportunities becoming ERP sales-order drafts. Test duplicates, updates, deletions, missing tax data, permission failures and ERP downtime using synthetic records. Then add the reverse flow for invoice status. Measure successful sync rate, exception age, manual corrections and time saved. These are more useful than a diagram showing two connected logos.

Microsoft's API design guidance recommends domain-oriented contracts and explicit idempotency for side-effecting operations. Those principles apply whether the integration runs on Azure, another cloud or a private network.

I work at OneBonsAI Gulf. Our system integration service covers scoping the ownership, APIs and operational controls around existing business systems.

Further reading: Microsoft Azure Architecture Center: API design.

A human approval step for an LLM agent: the boundary that matters

Lohith Lalesh — Sat, 07 Nov 2026 18:52:37 +0000

An agent can prepare a change without being allowed to make it. That distinction is the simplest way to get useful automation into an enterprise workflow while keeping a person accountable for consequential actions.

Consider a supplier onboarding assistant. It reads a request, checks whether mandatory fields are present, compares the supplier against an approved registry, and prepares an ERP record. It must not create the supplier or release a payment on its own. The approval step belongs between prepare and execute, not as a polite question the model asks after it has already called the write API.

Split the workflow into explicit states

A practical state machine is received → validated → proposed → awaiting_review → approved/rejected → executed → reconciled. Persist the proposal and its source references before asking for approval. An approver should see the original request, the exact fields to be written, the evidence used, uncertainty, and any policy warnings. The approval decision should refer to a versioned proposal ID, so an edited proposal cannot inherit an earlier approval.

The write operation should be a separate service endpoint. Give the agent read access and permission to create a proposal, while the execution service accepts only a valid approval token from the workflow system. A prompt such as “always ask before writing” is helpful guidance, but it is not an access control.

Make approval specific

“Looks good” is too vague. Ask the reviewer to approve the exact action: create supplier S-1042 with the displayed bank and tax details, or send the displayed reply to a named recipient. Show a diff against the current record. Let the reviewer edit, reject or escalate. For financial, identity, personal-data or regulated decisions, the appropriate reviewer and evidence may differ; encode those rules outside the model.

A minimal approval record contains the proposal ID and version, actor identity, action type, target system, payload hash, reviewer identity, decision, timestamp, reason, and execution result. Set an expiry and do not reuse the approval for a later attempt with a changed payload.

Handle failures after the click

Approval is not proof that the write succeeded. The executor needs an idempotency key so a retry does not create two suppliers. Record the target system's response and reconcile it with the intended change. If execution fails, leave the item in an exception queue rather than asking the model to invent a recovery path. Test the rejected, expired, modified, duplicate and unavailable-system paths before a pilot.

Microsoft's Agent Framework documentation describes a related pattern: an approval-required tool pauses the workflow and emits a request that an external reviewer can approve or reject. The exact SDK is optional; the durable pause and the separate authorisation boundary are the important parts.

Start small: choose one low-volume workflow, one write action and one reviewer group. Measure time from proposal to decision, reviewer corrections, false positives, and failed executions. Those measures tell you whether the agent reduced work or merely moved it to the approval queue.

I work at OneBonsAI Gulf. For teams planning a bounded agent with human oversight, see our agentic AI implementation service.

Further reading: Microsoft Agent Framework human-in-the-loop workflows.