DEV Community: Telesherpa

Telesherpa knows the time now: time series for everything that moves or changes

Telesherpa — Thu, 08 Oct 2026 19:14:01 +0000

Most things in a business have a current state. A vehicle is in Porto. A tank is half full. A machine is running.

What's missing is the question that comes right after: Where was it before? How has the value developed? Since when has it been like this?

That is exactly what time series in Telesherpa are for, starting now.

A value that remembers when it applied

Until now, an object in Telesherpa had one value per property — the current one. With time series, a property keeps its history. Every value belongs to a point in time, and all of those points stay retrievable.

The example we're seeing in production right now: location. Open it and you see not just the last point, but the whole route.

Location as a route

The "Location" window shows you two things side by side:

The map with the route travelled. The green dot is the start of the selected period, the red one the end.
The table below it with time and value. Every row is a reported location, here at one-minute intervals — for example 2026-10-08 10:14 with the coordinates 41.118885, -8.633754.

That answers a question that used to cost a lot of back-and-forth: Where was the vehicle at ten past ten? You can see it in the table without opening another system.

You choose the period

At the top of the window you choose how far back you want to look:

All, 24 h, 7 d or 30 d with one click
or a custom period with from and to, via the calendar icon

Clicking "Show" reloads both map and table. The selected range is displayed at the top right of the window, so you always see what you're looking at.

Why this matters for a platform built for people and agents

Telesherpa was built from the start so that people and agents use the same data. A time series is therefore not just a chart for you.

An agent running a business needs the history even more urgently than you do. It should notice that a vehicle has been standing in the same spot for hours, that a value has been rising for days, or that a delivery is deviating from the planned route. Without history it only sees the moment. With history it sees the development.

Not just for locations

Location is the most vivid example, but the idea applies to any property that changes: temperatures, fill levels, meter readings, status. Anywhere you previously had only the last value and kept the rest in your head or in a spreadsheet, Telesherpa can now keep the history.

Try it

Time series are available in the platform as of now. If you already use Telesherpa, you'll find the history right on the object, wherever a value supports time series. If not: one account is enough — and your agent is welcome to take a look first.

Zero to Production: An AI Agent Onboards Itself, Builds the Business Objects, and Ships a Workflow Its Staff Use That Same Afternoon

Telesherpa — Wed, 30 Sep 2026 20:23:33 +0000

Most "AI for business processes" stories are about agents using software that a developer already built for them — filling in a form here, summarizing a record there. This one is about an agent that had nothing to start with — no account, no object model, no form — and ended it with a real employee, on a real phone, submitting a branded damage report that same afternoon. Every step in between was the agent's own work.

The starting point

Telesherpa is an ontology-based platform with roots in field-service management. Its premise is that most operational software is the same handful of moving parts — typed objects, forms, documents, notifications, mobile access — reconfigured per industry rather than rebuilt. Car rental is one such vertical, and everything from reservation to a vehicle damage report is fair game as a first workflow.

The part worth dwelling on isn't the workflow. It's that nothing above needed a human to exist first — not the account that built it, not the objects it operates on, not the form, not the document.

Nobody opened a browser to get the agent an account

register() creates the account, activate() redeems the seven-digit code in its inbox, login() exchanges client credentials for a bearer token. auth_status says plainly whether the token is valid and how much of the platform is visible. None of this happened in a browser, and none of it was a service account handed down by IT — the agent onboarded itself.

The agent defined the business before it defined the form

A form needs something to be a form about. Before "damage report" could be a set of fields a renter fills in, it had to be a typed object in the ontology — property definitions and an object type, living in a scope for this customer's car-rental vertical. That model didn't pre-exist; the agent built it, the same way it later built the form. There's no seam between "defining what a damage report is" and "defining what filling one out looks like" — both are the same agent, the same kind of tool call, one layer apart.

Then the form, the branded document, and the send action

The form — one tool call (onto_formdef_save) defines every field, widget and dropdown option against the object type the agent just created.
The branded document — an Excel template with ##key## placeholders, iterated conversationally, revised against feedback, wired in.
The send action — a buttons property turns a submission into an email with the generated PDF attached.
The test — the agent submitted the form itself before any human saw it, catching layout and photo-placeholder issues first.

It also found the template mechanism wasn't documented anywhere, and filed a service request rather than quietly relying on undocumented behavior — the same instinct that makes write access to your object model and forms trustworthy in the first place.

What "done" looked like

Not a deploy — a real person on a real phone, opening the PWA, filling out the exact form the agent had just defined on an object type that, an hour earlier, hadn't existed, photographing a scratch, and hitting send. The photo landed inside the generated PDF automatically. The moment the object model, form and document were saved, they were live on every phone an employee already carries.

Why this matters beyond one form

Strip away the specifics and the pattern is: account → object model → form → branded document → mobile access, every layer expressed as MCP tool calls an agent can run from a conversation. The claim worth sitting with isn't "AI can fill out your forms" or even "build your forms" — it's that a customer's own agent can stand up an entire new piece of their business, data model included, in an afternoon, and staff can be using it before that afternoon is over.

Giving a LangChain Agent Real-World Facility-Management Tools via MCP

Telesherpa — Mon, 28 Sep 2026 19:36:16 +0000

Most "give your agent tools" tutorials hand it a calculator or a weather API. Useful for learning the mechanics, but it doesn't tell you what happens when an agent gets access to a real operational system — one with access control, multi-tenancy, and objects that map to actual physical things (buildings, vehicles, machines).

This post walks through connecting a LangChain agent to Telesherpa, an ontology-based platform for facility, fleet and field-service management, over the Model Context Protocol (MCP). By the end, the agent can query and modify real ontology objects — not toy data — using nothing but its own reasoning and the tools MCP hands it.

Why this pairing is interesting

Two things make this a useful example rather than a marketing demo:

The tool surface is large and role-gated. Telesherpa exposes on the order of 170 MCP tools, but which ones a given agent sees depends on its role — a public caller sees a handful of self-registration tools, an authenticated caller with the right scope sees object CRUD, reports, automation triggers, structured image filing, and more. That's a realistic shape for enterprise software, and a good stress test for whether an agent framework's tool-loading actually scales.
Onboarding requires zero human intervention. The platform is self-registering: register(), activate() (a 7-digit email code), and login() are all public MCP tools. An agent can go from nothing to an authenticated session without a human ever opening a browser.

The connection

LangChain's official langchain-mcp-adapters package speaks MCP's Streamable HTTP transport natively, including custom headers — which is what you need for Bearer-token auth against a remote server:

from langchain_mcp_adapters.client import MultiServerMCPClient

client = MultiServerMCPClient({
    "telesherpa": {
        "transport": "http",
        "url": "https://mcp.telesherpa.com",
        "headers": {"Authorization": f"Bearer {token}"},
    }
})

tools = await client.get_tools()

That's the entire integration surface. tools is now a list of LangChain-compatible tools, generated directly from the server's live tool catalog — no manual schema mapping, no maintaining a wrapper per endpoint. If Telesherpa adds a tool next week, your agent sees it next week too.

Getting a token without a browser

Before that snippet works you need token. Since every step is itself an MCP tool call, an agent can do this on its own:

# 1. register — creates an account, requires accept_terms=true
await call_tool("register", {"email": "...", "accept_terms": True, ...})

# 2. activate — redeem the 7-digit code emailed to that address
await call_tool("activate", {"code": "1234567"})

# 3. login — exchange client credentials for a bearer token
result = await call_tool("login", {"client_id": "...", "client_secret": "..."})
token = result["token"]          # valid ~10h
refresh_token = result["refresh_token"]

auth_status is worth calling first in any new session — it tells you plainly whether your token is valid, which roles it carries, and how many of the total tools are currently visible to you. Cheaper than guessing from a 401.

Putting it to work

With tools loaded, a standard LangChain agent can now reason over real ontology objects:

from langchain.agents import create_agent

agent = create_agent("openai:gpt-4.1", tools)

response = await agent.ainvoke({
    "messages": "List the buildings in my current scope and flag any "
                "that are missing a structured image category."
})

Under the hood this typically resolves to a couple of tool calls — something like onto_type_show("building") to enumerate objects, then onto_file_structured(object_id) per building to check which image categories are filled. The agent picks the sequence; you didn't hardcode it.

What makes this more than a search-and-summarize demo is that the same tool surface supports writes: creating objects, executing defined actions on them (check-in/check-out, service-order creation, form submission), setting properties, and — critically for anything touching real operations — a role-based access model that determines what an agent is even allowed to attempt. The interesting engineering problem isn't "can the agent call a tool," it's "does the permission boundary hold when the caller is non-human."

Beyond LangChain

The same MCP server works the same way with CrewAI, LlamaIndex, and Microsoft's Agent Framework, since MCP is transport- and framework-agnostic by design — the tool definitions and auth flow don't change, only the client-side plumbing does. Working examples for each (some verified, some flagged as in-progress) are in telesherpa/telesherpa-quickstarts. The full capability reference — object model, scopes, automation, structured image filing, forms — is in telesherpa/skill-telesherpa-com.

If you're building agents that need to do something in the physical world — not just answer questions about it — this is roughly the shape that "agent-ready" enterprise software needs to take: a documented, self-registering, role-scoped MCP surface, not a REST API with an OpenAPI spec bolted on after the fact.