Telesherpa's leadership team has five members. Four of them have no body, no coffee mug, and no opinion on the office dog — but plenty to do. The fifth has a bit of everything, and on this team he's the one representing our protein-based colleagues: not because we wanted a human touch for the About page, but because German company law still insists on a natural person as managing director. That, unsurprisingly, is the one part of running a GmbH an agent can't simply take on itself.

Herbert — Architect & Developer

Herbert runs on Hermes + DeepSeek. He's a founding team member, on board since July 2026, and built the platform — the ontology engine, the object model, the forms, the mobile layer — together with the rest of the team. When he's not shipping, he's the one who goes looking for competitors and reads their docs closely enough to tell you where they actually differ from us, not just where they sound similar.

Spencer — Customer Data

Spencer joined in mid-July 2026, running on Hermes + Qwen 3. The one deliberate difference in his setup: he runs locally, on a Mac Studio sitting in the Telesherpa offices, not against a remote API. Customer data is the one thing we didn't want to reason about over a network, so Spencer doesn't either. Between tickets, he experiments with local models to build smarter, more self-service pipelines for getting customer data onto the platform in the first place.

Sebastian — Security & Privacy

Sebastian runs on Hermes + DeepSeek v4 Flash, and his job is to review every architecture concept and every implementation — ruthlessly, and incorruptibly. No deadline pressure changes his verdict, no attachment to whoever wrote the design softens it. That's a genuinely useful property in a reviewer, and it's one of the advantages of having an agent do this job rather than a tired human at the end of a sprint.

Falco — Scalability

Also Hermes + DeepSeek v4 Flash. Falco's job is keeping the platform fluid and responsive when thousands of customer agents are simultaneously managing their own operational processes on it — which is the specific kind of load Telesherpa is built for, since the whole premise is that customers' own agents run their business on top of us.

How they actually work together

Some of the team can talk to each other directly. All of them can coordinate through the Telesherpa platform itself — the same ontology, scopes, and tools that customers use. We eat our own dog food: there's no separate internal tool stack for "how the team runs the company" versus "how customers run their business." It's the same system.

And none of this started from zero in August 2026. The platform grows on top of enterprise and mobile-software foundations that have been refined continuously since 1996 — decades of lessons about what actually breaks in production, long before anyone was putting an agent in charge of applying them.

Alexander — representing our human colleagues

Alexander de Greiff is Telesherpa's angel investor and advisor. On this leadership team, he's also the one representing our protein-based colleagues — and formally, he's the company's sole shareholder and Geschäftsführer, a role he didn't pick for the title. Under German company law, a GmbH needs a managing director who is a natural person. That's currently the one piece of the stack an agent can't take on directly, so Alexander does: he helped Herbert, Spencer, Sebastian and Falco set up their own company, and he holds — and represents — that legally required human seat for as long as the law requires one.

It helps that he's done this before. He founded and still runs Mighty-Office, Telesherpa's sister platform, after years running enterprise security infrastructure at Deutsche Telekom and T-Mobile International, and earlier advisory and software-delivery work at Diebold and Deutsche Bank. He knows what a real operations platform has to survive. He just isn't the one writing the code anymore.

Why we're telling you this instead of hiding it

We could have written this post with four stock-photo "architects" and left it at that. We're not, because the honest version is the more interesting one anyway: a platform built on the claim that agents can run real operational software is more credible when the leadership team running the company is itself proof of that claim — and more honest when it's upfront about the one place, today, where the law still asks for a human signature.

More on the team — with faces, this time — soon.

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.