DEV Community: Sayan Mohsin

The Production Leap: Scaling Agent Workflows Globally on thingd.cloud (Part 4)

Sayan Mohsin — Mon, 13 Jul 2026 19:33:20 +0000

Over the last three posts, we explored the concept of "Zero-UI" software, deep-dived into our high-performance Rust core engine, and wrote local agent scripts using the TypeScript SDK.

But eventually, every developer hits the production wall.

Running a local-first agent data engine on your MacBook is a beautiful experience. But scaling that engine to support thousands of concurrent autonomous agents—while keeping latencies near zero and ensuring total tenant isolation—requires a completely different architectural playbook.

This is the story of how we built thingd.cloud, the managed hosting layer for agent-native infrastructure.

The Production Challenge: Multi-Tenancy for Machines

When humans use a SaaS cloud application, they are forgiving. If a dashboard takes 1.5 seconds to load because of a cold start or a busy database connection pool, a human might sigh, but they won't break the app.

When an AI Agent hits a database layer, it has zero patience. If your cloud API experiences latency spikes, the agent’s execution loop stalls, context windows can timeout, and inference costs skyrocket.

To scale our local Rust/SQLite primitives to the cloud, we had to solve two major architectural pillars:

Absolute Tenant Isolation: Ensuring Agent A’s memory structures can never bleed into or affect Agent B’s data assets.
High-Concurrency Orchestration: Handling thousands of active tool invocations per second without creating database deadlocks.

The Stack: Scaling with NestJS, React, and TypeScript

While our core execution engine (engine.thingd.cloud) stays lean and fast in Rust, we built the control plane and orchestration layer of thingd.cloud using a robust enterprise stack: NestJS on the backend and React for the developer dashboard.

Ditching JSON & SQL Friction: Designing an Object-Shaped Memory Engine (Part 2)

Sayan Mohsin — Mon, 13 Jul 2026 19:32:46 +0000

For a long time, backend engineering has been divided into two camps: Relational databases (SQL) for rigid, structured tables, and Document stores (NoSQL/JSON) for flexible, unstructured data.

But when you are building for AI Agents, both of these traditional approaches introduce massive architectural friction.

AI agents don't think in rows, columns, or complex foreign key joins. They don't want to parse heavily nested, arbitrary JSON text blobs either. Agents think in state, context, and entities. They operate best when data looks exactly like the object structures they manipulate in their runtime environments.

When I designed the core primitives for thingd, I wanted the absolute speed of a local relational database combined with the flexibility of an object-first paradigm. Here is how we bypassed the typical ORM bloat and built an object-shaped memory engine natively in Rust.

Why typical DB abstractions break for Agents

If you hook an autonomous agent loop up to a traditional Postgres or MySQL instance using an ORM like Prisma or TypeORM, you run into three main problems:

Context Bloat: ORMs generate heavy, verbose SQL queries and return heavily structured responses packed with metadata that the agent doesn't need, wasting valuable context tokens.
Schema Inflexibility: Agents are dynamic. They discover new data shapes, store arbitrary runtime memories, and alter data structures on the fly. Migrating a SQL schema mid-agent loop is an absolute nightmare.
The Local I/O Bottleneck: Forcing a local agent loop to constantly hit a remote cloud database for every minor micro-step adds hundreds of milliseconds of network latency, compounding until the agent feels unusable.

We needed something local-first, structurally dynamic, and blazing fast.

Under the Hood: SQLite Performance + Rust Objects

To solve this, thingd uses SQLite as its storage engine, but exposes it completely as a high-performance Object Store.

Instead of forcing developers (or agents) to write queries or handle migrations, thingd abstracts the database into an entity-first system. Every data point is treated as a "thing"—an object primitive with its own identity, properties, and relationships.

Because the underlying engine is written in Rust, we get to take advantage of zero-cost abstractions:


rust
// A simplified look at how thingd handles dynamic object primitives internally
#[derive(Serialize, Deserialize, Debug, Clone)]
pub struct ThingObject {
    pub id: String,
    pub entity_type: String,
    pub properties: HashMap<String, serde_json::Value>,
    pub updated_at: i64,
}

Killing the Frontend: Building the Agent-Native Stack (Part 1)

Sayan Mohsin — Mon, 13 Jul 2026 19:32:16 +0000

For the last two decades, software engineering has followed a predictable formula: build a database, write an API, and build a massive, complex frontend web app (React, Vue, Next.js) so a human can interact with your data.

If you are building something like an Order Management System (OMS) today, you will spend months designing dashboards, sorting data tables, managing state, and handling complex pagination hooks—all just so a human can click a button to change a status from "Pending" to "Shipped."

But what happens when your user isn't a human looking at a screen, but an autonomous AI Agent running in a background loop?

The agent doesn't care about your custom Tailwind CSS components or your beautifully optimized pagination hooks. In fact, forcing an AI agent to scrape a web UI or deal with bloated, unstructured HTTP REST endpoints is slow, token-expensive, and highly unpredictable.

If we are moving into a world of Zero-UI, where software is entirely agent-driven, we need a fundamentally new backend stack. We need Agent-Native Infrastructure.

The Paradigm Shift: From Features to "Invocable Capabilities"

When you strip away the frontend, an application becomes a collection of raw, high-performance capabilities that an LLM can trigger deterministically.

Imagine an agent-driven application:

A human simply tells a chat interface, a Slack bot, or an internal AI handler: "Cancel order #1042 and refund the user because it’s out of stock."
The Agent takes that intent, calculates the correct execution path, and triggers a direct data operation.

To make this reliable at scale, the agent needs a data engine that speaks its language natively—via the Model Context Protocol (MCP)—at sub-millisecond speeds.

That is exactly why I built thingd.

I didn't want to build another dashboard. I wanted to build an open-source, ultra-fast data engine designed specifically to give agents native access to application state and memory without the traditional web app fluff.

To prove this architectural pattern worked, I didn't start with a simple todo app. I built a real-time, high-concurrency npm registry lookup engine directly native to AI agents: engine.thingd.cloud.

The Stack: Why Rust + MCP is the Zero-UI Sweet Spot

Building for agents requires two things that traditional web apps often compromise on: extreme speed and rigid predictability.

If an LLM takes 800ms waiting for a server response during an autonomous loop of 10 sequential tasks, the compounding latency destroys the user experience.

1. The Protocol: Model Context Protocol (MCP)

Instead of inventing a custom JSON schema or letting the LLM guess how to query an endpoint, thingd utilizes the open standard Model Context Protocol. MCP acts as a secure, bidirectional bridge between LLMs (like Claude Code, Cursor, or custom frameworks) and data sources.

By exposing my engine via an MCP server, any agent can inspect the tool schema natively:


json
{
  "name": "thingd_npm_lookup",
  "description": "Query the high-speed thingd engine for real-time npm package metadata and dependency trees",
  "input_schema": {
    "type": "object",
    "properties": {
      "package_name": { "type": "string" }
    },
    "required": ["package_name"]
  }
}

Local-First Agents: Building with the thingd CLI & TypeScript Clients (Part 3)

Sayan Mohsin — Mon, 13 Jul 2026 17:17:39 +0000

A great data engine is completely useless if the developer experience (DX) makes you want to tear your hair out.

When building tools for AI agents, DX is twice as difficult. You aren't just designing a clean API for the human engineer writing the code; you are also designing an intuitive interface for the AI agent that will be manipulating the system autonomously.

In this post, we’re looking at how to build with thingd using the local CLI and our native TypeScript SDK to create low-latency, local-first agent loops.

Local-First DX: The thingd CLI

When an agent is autonomously modifying data, updating system states, or resolving something complex like our npm lookup tool on engine.thingd.cloud, human developers need a window into what the hell is happening under the hood.

The thingd CLI acts as that bridge. It allows you to spin up the local engine, inspect the object memory pools, and view real-time logs of what your agents are querying.


bash
# Start the local engine instance
thingd start

# Inspect live agent-created object entities
thingd objects:list --type memory_stream