Agents

Software that answers for itself.

Autonomous systems that run without anyone starting them: a receptionist that reads the inbox, one that will answer the phone, and the scheduled jobs that keep this site current. Every one of them is running on this domain, and the status below each is the real one, including the ones that are not finished.

The receptionists

Two front doors, both answered.

DataRail publishes an email address and a phone number. Both of them are now the job of an agent, built here rather than rented from a platform. They capture and qualify enquiries: what you need, roughly what scope, what timeline, and whether there is a budget attached.

Email receptionist

Built · not yet answering

watches contact@datarail.org · every 30 minutes

Reads what arrives, works out whether a human wrote it, and answers the ones that are real. It knows what DataRail does from a curated file rather than from the open web, so it cannot offer you a service that does not exist. Spam, newsletters and machine mail are filed in silence and never answered.

What it gathers goes into a structured lead record with a score, so a serious enquiry does not sit unread behind forty newsletters.

It books the call too. It reads the real calendar, offers times that are actually free, and when you pick one it puts the call in the diary and sends the invitation — re-checking availability first, because the gap between an offer and a reply can be days.

ReasoningOpenAI, deliberately not the same vendor as the rest of the stack

Runs onA scheduled job, no server to keep alive

BooksAgainst a real calendar, never a time it invented

SendsAutonomously, within limits it cannot exceed

NeverQuotes a price, promises a date, or invents a capability

Voice receptionist

Design notes · awaiting hardware

answers 718 838-9901 · built, not rented

A telephone receptionist assembled from the parts rather than bought as a service: our own softswitch, our own trunk, our own speech models on our own GPU. The audio never goes to a voice-agent vendor, because there is not one in the path.

Honest status: this is specified, not running. The speech models need a GPU that is not yet installed, and until it is, there is nothing to demonstrate. The specification is written and the carrier work is understood; the hardware is the gate.

TelephonySelf-hosted softswitch on a wholesale SIP trunk

SpeechTranscription and voice generated locally, on our own GPU

SharesThe same lead store and the same rules as the email agent

Blocked onHardware, and saying so rather than showing a mock-up

How they are built

An autonomous system needs rules it cannot talk its way out of.

These agents send things to real people with nobody reading first. That is only defensible if the limits are structural rather than a polite request in a prompt. Every rule below is enforced in code, outside the model.

It tells you what it is

Every autonomous reply says it was written by an assistant and that a human is reading the thread. A receptionist that hid what it was would be the only dishonest thing on this domain.

It cannot name a price

DataRail quotes in writing after a free call, so the agent has nothing to offer. Any draft containing an amount, a rate or a guarantee is blocked before it reaches the mail server and held for a person.

It cannot invent

It answers from a hand-written file of what DataRail actually does, not from the live site and not from its own memory. Anything outside that file gets an honest “I will check”.

It fails quiet, not loud

Anything it cannot classify gets no reply at all. Silence from a machine costs nothing; a confident wrong answer to a client costs a great deal.

It has a ceiling and a switch

Hard caps on messages per run and per conversation per day, so a loop hits a wall long before it hits a mailing list. One repository variable stops it entirely, with no deploy.

Everything is on the record

Every decision, including every decision not to reply and the reason for it, is written to a log. The lead history lives in version control, so what the agent knew and when is recoverable.

Already running

The unglamorous ones, which have been working for months.

Not everything autonomous needs a language model, and most of what keeps a site alive should not have one. These are scheduled systems with no reasoning in them at all, which is exactly why they are dependable.

Events feed builder Twice daily Pulls nightlife and electronic music listings from an external API, filters and deduplicates them, commits the result and triggers its own deploy. Refuses to publish an empty board when a source goes down. Flipper emulator build On every change Compiles C firmware apps to WebAssembly and republishes the browser emulator whenever the shim or an app changes. No local toolchain involved; the pipeline is the only build. Site deploy On every push Ships the site to its webspace over SFTP on every change, with a dry run available and deletion switched off, so a bad push can add or overwrite but never remove.

Want one of these answering your phone?

This is the third of the four things DataRail does: putting models into workflows that actually run, including the unglamorous half — cost control, failure handling, and what happens when the model is wrong.

Book an intro call