Build with Tares

Tell Tares, in a sentence, what you want watched and what should happen when something goes wrong. It works out the rest with you and, at the end, an agent is watching your systems around the clock: reading the data as it arrives, noticing the condition you described, and writing its finding, to Slack or wherever you said, while you are doing something else.

That is the whole point. You do not have to know how Tares is put together, which connector carries which signal, or what a view or a trigger is. You bring what only you have: where your systems run, a token or a URL where one is needed, the threshold that matters to you, what a useful finding should say. Tares brings the rest, one proposal at a time, and nothing happens until you confirm it.

What you end up with is real and yours: the data connections, the condition, the agent and its prompt, each editable on its own page and grouped as a project so you can see, pause or remove the whole thing at once.

Where it is

Projects → Create new. On an instance with no project of its own yet, the Overview opens on it as well. The template gallery is behind Use a guided template on the same page, and the AI SRE demo is an offer there, created only when you ask for it.

The steps

Sources. The assistant reads which connectors are installed and which sources already exist, then proposes the sources your goal needs, each as that connector’s form, prefilled with what you told it. The fields only you can fill (a token, a URL, a container name it could not know) are marked yours to fill and left empty; the model never invents a secret. Test connection runs one poll before you press Create source. A source that already exists with that name is offered as Use the existing source instead of a duplicate. Once a source exists, the card keeps its ingest endpoint and setup snippet, because a push source is nothing until something posts to it.

Views and triggers. One step, because “what should fire” is one question. The proposals are grounded in the fields the connected sources actually carry: labels where a source needs them, a view per entity, then the triggers on that view with threshold, window and cooldown. Apply takes a card as is; Edit opens the view or trigger editor with the proposal filled in.

Agent. One proposed Tares agent, as the agent form. The assistant asks what the agent should do when the trigger fires before it writes the prompt, and picks only the delivery kind (Slack, webhook, or the timeline only); the channel is always yours to pick, and a webhook URL you typed is carried into the form. Start creates the agent, enables it (which checks that an Anthropic key resolves) and adds it to the project.

Done links to the project page.

How it behaves

• It asks before it guesses. When the goal leaves a real choice open (which API, which places, which thresholds, what the agent should conclude) the assistant asks up to three short questions and proposes nothing until you answer, in the box under its message. A goal that already says enough gets proposals straight away.
• A goal that matches a template becomes that template. If what you describe is what a template sets up, the assistant proposes the template as one card, its own parameter form prefilled, rather than assembling the same thing from parts. A template whose project already exists on the instance is answered with You already have this and a link, since a template’s objects have fixed names and exist at most once.
• Nothing is created until you click. Every proposal is a card; Apply, Create or Start calls the object’s normal API, with the same validation as the console forms. The assistant has no write tool, and each step’s turn is given only that step’s proposal tools, so a sources turn cannot produce a trigger card.
• Change what you need at any point stops the current turn and reopens the goal. Propose again restarts from the sources step with the new goal: proposals you had not applied are dropped, and the objects already created stay in the project and are named to the assistant so it builds on them rather than proposing them again.
• Leaving part way keeps what was created. The project exists from the first source on, and everything applied is a real object on its own page. Resuming an interrupted build is not supported; the project page is where to pick it up.

What it needs

An Anthropic key on the instance, the same one Ask and Tares agents use. Without one, the builder asks for it first and continues the moment it is saved. On Tares Cloud a new cell is born with a trial key.

On the API

The builder is the Ask chat loop in build mode:

Proposal cards arrive on the stream as proposal events with a kind of source, labels, view, trigger, agent or project. The console turns them into forms; the create calls are the ordinary ones on /api/sources, /api/views, /api/triggers, /api/agents/builtin and /api/projects.