Helpers

Overview

Syncropel coordinates more than chat assistants. A helper is an automated participant that does one kind of work well and returns its result as a record. A scheduling solver that optimises a route, a classifier that tags incoming records, a checker that validates data against a set of rules — each is a helper.

What makes a helper a helper rather than an agent is its mechanism. An agent drives a work loop with a language model, taking many turns and calling tools along the way. A helper is usually a single, focused computation: it takes a request, produces an answer, and is done. The answer might come from a mathematical solver, a trained classifier, a rules engine, or several of these combined — Syncropel does not care how a helper computes.

What it cares about is the same thing it cares about for a person or an agent: a helper is an actor. It has a DID, a trust profile, a tier, and an audit trail of records on the threads it works on. Nothing about a helper gets a second identity model just because it is not a language model.

chat assistant ─── language model, many turns ─┐
solver         ─── one computation, one answer ─┼──▶ same actor, same trust, same audit trail
classifier     ─── one computation, one answer ─┘

How work reaches a helper

A request for work lands on a thread the way any coordination event does — as a record. Syncropel routes that request to the helper best suited to it, the helper returns its result as a record on the same thread, and a reviewer's verdict on that result feeds the helper's trust. The request, the result, and the verdict are all plain records, so anyone with thread access sees exactly what was asked, what came back, and whether it was accepted.

Over time this is how Syncropel learns which helper to trust for which work. When more than one helper can do a kind of work, Syncropel prefers the one with the stronger track record in that domain. Trust is earned from outcomes that get reviewed, not declared up front — a helper that consistently produces accepted results becomes the one work routes to, and one whose results are routinely overridden does not. Because trust is domain-scoped, a helper that is reliable at one kind of work and unreliable at another is reflected correctly.

Why this matters

Most coordination tools assume the only automated participant is a chat assistant. Syncropel does not. By treating every automated participant as an actor that produces auditable records and earns trust from reviewed outcomes, it can route a scheduling problem to a solver, a tagging problem to a classifier, and an open-ended research problem to a language-model agent — and weigh each one by how well it has actually done that kind of work, not by what it claims it can do.

The result is a single, honest picture: whatever did the work, the record shows what was asked, what came back, who reviewed it, and how that outcome moved the participant's trust.

Deploying a helper today

Wiring a custom helper into an instance is an advanced, owner-driven step today: the instance owner configures the helper, points it at the work it should handle, and the helper begins participating as an actor. It is not yet a self-service flow — a "bring your own helper" path you can use without touching configuration is on the roadmap, not something to rely on yet. The built-in Scribe assistant and the language-model agents you start with @agent are available on every instance out of the box; additional helpers are something an owner adds deliberately.

Where it fits

• Actors — the identity primitive every helper inherits.
• Agents — the language-model member of the helper family, driving a work loop.
• Trust — how reviewed outcomes decide which helper work routes to.
• Threads — where a request reaches a helper and its result comes back.