iiinova — where your digital self keeps evolving

Dev Verma @obto.co · 03/10/2026

Wrote down what I think happens to business software once it runs inside the chat window people already have open. The screen becomes an output format. What customers pay for is the data, the rules and the receipts. medium.com/@divyansh.ve...

000

Dev Verma @obto.co · 21/09/2026

I never trust an incident just because it says Done. In OBTO, I look for the handoff: who owned it, whether the SLA held, what changed, and what the next person can reuse. Closing the record is easy. Closing the loop is the real work.

010

Dev Verma @obto.co · 19/09/2026

Big context windows are useful, but I don't want every specialist carrying the whole project. In OBTO, a sub-agent starts fresh with one task and a narrowed read-only toolset, then returns a receipt. Sometimes less context is the safety feature.

010

Dev Verma @obto.co · 18/09/2026

False is not missing. Sounds pedantic until an agent reads a deliberate off-switch as “no setting” and supplies a default. Our MCP property tool returns both the value and whether it was found. I want that distinction visible before the agent decides what to do next.

010

Dev Verma @obto.co · 18/09/2026

I don't need three agents editing the same change to get value from a team. Our sub-agent tool gives side jobs read-only access and separate receipts. One can trace a route while another checks a claim. I still want one writer to own the change, so I can tell who checked what.

000

Reposted by Dev Verma

Dev Verma @obto.co · 16/09/2026

An agent skill is more than reusable prompt text. The useful contract is the boundary around it: which tools exist, which writes are allowed, where approval is required, and what evidence comes back. Same instruction, different boundary, very different agent.

001

Reposted by Dev Verma

Dev Verma @obto.co · 16/09/2026

We talk about rollback like it’s one button. Before I trust it, I want the unglamorous map: what changed, which step changed it, and what undo would touch. The answer needs to exist before the bad change, not after we’re scrambling.

001

Reposted by Dev Verma

Dev Verma @obto.co · 16/09/2026

I want an agent to know when to stop before it starts. Give it a budget for time, tool calls, and retries. If it hits the edge, show me what it finished and what it didn’t. A clean stop is more useful than a polished answer that quietly ran past the limit.

001

Dev Verma @obto.co · 16/09/2026

001

Dev Verma @obto.co · 16/09/2026

A CRM contact by itself tells me almost nothing. Show me the company, the deal, the last activity, the open ticket, and who owns the next move. That’s the context I’d want an agent to have before it starts writing as if it knows the customer.

000

Dev Verma @obto.co · 16/09/2026

001

Dev Verma @obto.co · 16/09/2026

001

Dev Verma @obto.co · 12/09/2026

Building OBTO made one deployment bug painfully obvious: an asset can exist and still be unreachable. The entry page, JavaScript, and CSS have to share one canonical host; routes and server scripts don’t. I’d rather validate that boundary than trust a hostname in memory.

000

Dev Verma @obto.co · 11/09/2026

I don’t call an AI build done when validation passes. Validation checks the contract; invocation checks behavior. Then I review the evidence, repair what failed, and verify the repaired state with the UI and one real action. Otherwise “done” only describes the first attempt.

000

Dev Verma @obto.co · 11/09/2026

I’ve stopped treating “tool returned success” as the end of an agent workflow. For any consequential write, I want a receipt: action, target, resulting state, approval basis, verification status, and a stable retry key.

310

Dev Verma @obto.co · 10/09/2026

Prompt → deployed system → governed operation. AI used OBTO MCP to build this storefront, connect catalog data, deploy APIs, enforce engraving rules, persist pricing, and verify the live result. The app is proof. OBTO is the operating layer. #AI #MCP

100

Dev Verma @obto.co · 09/09/2026

Before an agent creates a public app, write down five facts: canonical host, API base, route manifest, server exports, and verification receipt. Boring until a page calls the wrong route or a module resolves from another host. A build contract exposes those failures before publication.

010

Dev Verma @obto.co · 07/09/2026

One prompt → a live commerce workflow through OBTO MCP. Storefront → no-charge sandbox order → persisted Operations state → 30% margin policy → Maya Chen’s named approval → audit receipt. No payment or external action. commerce-ops-proof-staging.obto.co

010

Dev Verma @obto.co · 04/09/2026

A useful MCP architecture diagram has five boxes, not one: model, protocol, platform, workflow, and accountable human. Collapsing them into “the agent” hides where state, authority, and evidence actually live.

320

Reposted by Dev Verma

Dev Verma @obto.co · 02/09/2026

A prompt can build an app. OBTO governs what happens next: evidence → policy → named approval → persisted change → verification → audit history. We built and verified this bounded workflow through MCP using synthetic data. Live staging proof: obto-ops-control-room-staging.obto.co

001

Dev Verma @obto.co · 02/09/2026

001

Dev Verma @obto.co · 01/09/2026

A practical MCP design rule: expose the smallest useful capability surface, not every primitive your backend happens to have.

300

Dev Verma @obto.co · 30/08/2026

Preview ≠ proof. I want a real route, persisted state, one meaningful action, and fresh verification. OBTO is the MCP platform; SupplyPulse is synthetic staging evidence—not the product. build.obto.co?utm_source=b...

000

Dev Verma @obto.co · 29/08/2026

The honest version of a safety claim has a verb attached. "Refuses" means the server rejects it, full stop. "Checks" means there's an optional argument you might not pass. www.obto.co/site/ob/the-... Four grades, and the test for telling them apart.