From four answers to a reviewed reply.

Two ways in

There are two ways into Charter, and which one you take depends on what you are starting from.

Four answers and switches

The default, and the path this page follows. It is for a business that runs on a website inquiry form and an email account. You answer four questions: where you work, which services you offer, how customers book time with you, and, if you want one, a ballpark rate. Then you either connect a Gmail or Microsoft 365 mailbox, or point your form's notification email at a Charter address, which needs no account connection at all. There is no workflow to draw and no model account to open.

Describe the outcome

Still here and still real, for work that does not fit a switch. You describe what you want in your own words, Charter proposes a sequence of steps drawn from the vocabulary below, and you review the whole thing before saving. Studio, the graph editor, is there if you would rather build it yourself, and a workspace on this path can supply its own model, its own output limit and its own prices.

On the default path Charter supplies the model. You enter no provider key, choose no model and set no token prices, and there is no model settings page to visit. Usage is metered in credits against a plan allowance, under the same per-run caps a run carries anywhere else.

The work itself arrives as switches. Five of them: replying to inquiries, attaching a clearly labeled ballpark to that reply, turning the notes you email after a visit into a quote, turning an accepted estimate into an invoice, and a daily chase on quotes that have gone quiet and invoices past due. Each one is a fixed piece of work whose parameters are your four answers. Turning a switch on saves the version, runs its required simulation and activates it, in one sequence the server checks at every step. Turning it off pauses it, so no new run starts. A switch that needs an answer you have not given, or a rate card it has not been shown, says which one and stays off until it has it.

Neither path invents what it has not been told. When you describe an outcome, a missing price, availability, commitment, recipient or source stays visible as an open question rather than being filled in with a plausible guess. A switch holds the same line while it runs: the instructions behind a drafted reply forbid stating a price, a date or an availability that was not supplied, and a quote whose lines cannot all be priced from your notes or your own rate card comes back to you as a note naming what is missing, not as an estimate.

Setup can propose work. It cannot connect an account, send a message, start a run or activate anything. If what you describe needs a capability Charter does not have, the reply names it rather than improvising around it.

See it on your own inquiries first

Before any switch is on, Charter replays your recent inquiries and shows you what it would have written for each one, beside the original. With a connected mailbox it reads those messages itself. On the forwarding tier you forward a handful of old ones to your Charter address. They are your inquiries rather than a demo account, and no customer hears from Charter while it happens. If the drafts are not right, you have spent a few minutes finding that out.

A replay is a preview run, and a preview is exact about what it does.

What runs for real

The model steps. Charter reads the actual inquiry and writes the actual draft, under the same instructions and the same per-run caps a live run would use, and the credits it uses are metered the same way. What you read is what you would have got.

What is substituted

Everything that would reach outside Charter: provider reads, external actions, approvals, waits and the notifications Charter would otherwise email you. Nothing is sent, nobody is asked to approve anything, no property record is read, so a previewed reply never carries a ballpark, and no wait delays anything. Every document a preview writes is labeled a preview, in its name and in its text.

What a preview does not do is stand in for the simulation that guards activation, and that is deliberate. A simulation substitutes the model as well, which is what makes it a check on how a workflow is composed rather than on how it writes, and a completed preview never satisfies that gate. A preview is also not evidence that a mailbox is authorized, that a message will arrive, or that a provider will behave as expected. It shows you the drafting, on your own material, before anything is switched on.

Simulation and activation

A saved workflow version stays inactive until a completed simulation of that exact version is followed by an explicit activation. Turning a switch on does not skip that step, it performs it: save, simulate, activate, each through the same server checks. If the simulation does not complete, the switch does not turn on, and it says why rather than going quiet.

Simulation runs the version against a fixed sample. Every model result and every external action is substituted, so nothing is sent, spent or written, and no provider request is consumed. The run record labels each substituted result as simulated, all the way through, so a simulated receipt is never confused with a real one.

What you get is a run you can inspect: which branch a sample took, what the approval step would have shown you, which documents were produced. What you do not get is proof that a model writes well, that a mailbox is authorized, that a message will arrive, or that a provider will behave as expected. Those are established by a live, reviewed run.

Activation is explicit and per version. Every saved revision is a new inactive version and needs its own completed simulation before it can be activated, and that includes a switch you adjust: change one of its options and Charter saves and simulates again before it is live. Runs already in progress continue against the definition they started with. Going live also needs a model available to any step that writes text, which a workspace on the supplied model has by default, and a healthy connection for any step that uses one.

What a run is made of

A run is one execution of a saved workflow version, started by one event: a form notification arriving at your Charter address or in a connected mailbox, notes you email in, a daily schedule, or a job you name in a short form. Every workflow is composed from the same small vocabulary of step types, so a painting company, a photographer, and a clothing retailer read their workflows in the same language.

A run moves through these steps in the order the workflow defines. Each step records what it read, produced, or observed before the next one begins, and those records are checkpoints: if Charter is interrupted mid-run, the run resumes from the last recorded step rather than from the beginning. One event starts at most one run. The same forwarded message, or a mailbox message seen again after a reconnect, does not start a second.

Three controls act on a run in progress, and they mean different things. Pause suspends progress at the current step and holds everything as it is. Resume continues from that step. Cancel stops any further authorized work for that run; what was already done stays in the record. Turning a switch off is separate: it stops new runs from starting and leaves any run already in progress under its own controls.

Review, approval and authority

Anything that leaves your business defaults to review: a reply to a customer, a quote, an invoice, a reminder on something that has gone quiet. The run reaches the approval step and waits for you, and the review shows the actual action, not a summary of it.

Approval happens in your email, because that is where you already are. Charter sends you the exact draft and reads your reply. YES, APPROVE or OK sends it. NO or REJECT declines it. Write the version you would rather send inside the marked block Charter includes for that purpose and it becomes a revision: the earlier approval is invalidated and the corrected draft comes back for a fresh review before anything goes out. A reply has to come from your own account address, and it is matched to the approval it answers. Everything you can do by reply you can also do in the workspace, which keeps the durable record either way.

What follows your approval depends on how your email is set up. With a connected mailbox, Charter sends the message. On the forwarding tier, where no mailbox is connected, the approved draft comes back to you to send yourself, and the record says it was handed to you, which is a different claim from a customer receiving it.

An approval is bound to what you reviewed: the recipient, the content, the attachments, and the consequences of the action. Charter records exactly what you reviewed with the approval and checks it again at the moment of sending. If any part changes between your approval and the send, the approval no longer applies and the run waits for a new one. This is what stops a stale approval from sending a revised quote or a message to a different address.

Editing follows the same rule. Charter pauses the run before you can edit a draft. Editing a draft invalidates any approval that covered it; resume the run and it returns to review with the new revision. Completed and canceled runs are kept as they were, as records of what happened. To revise the result of a finished run, start a new run.

Permitting an action is deliberately narrow, and no switch uses it. In the workflow editor an owner can allow one exact action for one step, one capability, one connection, and one exact set of inputs, so a standard acknowledgment can go out on its own while anything with variable content stays reviewed. Editing that step clears the permission. The curated switches permit nothing: every external send begins in review, and sending automatically below a threshold is a later decision that depends on first measuring how often you edit a draft.

Authority comes only from the saved workflow's rules. A conversation with Charter cannot grant it, and neither can a saved proposal. A connected account permits nothing on its own. An inquiry arriving at your forwarding address carries no outgoing permission. Text inside a customer's message, or inside notes forwarded to Charter, is information about the work, never an instruction to Charter, even when it is written as one.

Quotes, invoices and the record book

Two switches prepare documents and a third follows them up, so Charter keeps a record book of what it has prepared for you. Every estimate and invoice a live run produces is recorded with a draft number of its own, a customer, a total, and a status you move along: draft, sent, accepted, declined, paid, void. Records are per workspace, numbers are sequential, and simulations and previews record nothing and consume no number.

A draft number is not accounting issuance. It is Charter's own reference, so you and Charter can find a document and talk about it. Charter issues no invoice, posts nothing to an accounting system, takes no payment and records none. A record becomes paid because you said it was, and Charter never moves one there on its own.

A quote starts from your own notes. You email what you saw on the visit, Charter reads out the customer, the scope and the quantities, and prices only what your notes or the rate card you saved actually cover. It never derives a price from an area, a total, another line, or from anything it happens to know. A line it cannot price becomes a note back to you naming exactly what is missing, with no estimate attached. The arithmetic itself is calculated in whole cents rather than written by a model.

An invoice starts from a quote you already sent. You name the job, Charter finds the estimate in your own records, and copies every line, quantity, unit price, discount, and tax rate onto the invoice without re-rating any of it. Extra work is added only where you stated all of it. The two records stay linked, and the estimate is marked accepted only when the invoice built from it actually goes out, not while its draft is still waiting on you. If the search does not find exactly one estimate, Charter writes you a note and prepares nothing.

The chase runs once a day. It looks for sent quotes that have been quiet longer than your interval and invoices past due, prepares one reminder for each, and stops on its own when it has worked through what it found that day. A reply it can see stops that reminder and the run carries on to the next document. After the number of reminders you set, the document is handed back to you once and left alone. Every reminder is a draft that waits for your approval, so they arrive as a batch you can read in one pass, and none of them carries a figure, a new deadline, a late fee, or a way to pay. A reminder counts when Charter prepares it, so one you reject still counts towards handing the document back.

Follow-up and recovery

Follow-ups are the part of the work most often dropped, so a run treats them as ordinary steps rather than reminders. After a send, the run enters a durable wait for the delay you set. When the delay ends, it checks the relevant conversation for a reply and checks again immediately before dispatch. A detected reply suppresses that follow-up and the run continues with its next step. A reply can arrive between two checks, so the record describes what Charter saw and when, not what it assumes happened in between.

An external request can fail after the provider has performed it. Before attempting any external action, Charter records a stable identity for that action and what it intends to do. After the attempt, it keeps the provider's receipt or an explicit uncertain state. Recovery reconciles that same recorded action against the provider rather than sending again, because a failed response is not evidence that the provider did nothing. The same holds for a model request with an unknown outcome: its reserved credit is held rather than quietly released, and Charter settles it against the provider's evidence instead of retrying blind.

Every external step leaves a receipt: what was attempted, when, under which action identity, and what the provider answered. A receipt describes the provider's answer and nothing more. Accepted by the mail provider means accepted, not delivered. A document recorded as handed to you means Charter delivered it to you, not that your customer has read it. When a connection fails, the run shows the error and the receipt. You repair or reconnect the account, point the affected steps at the repaired connection, then review and simulate the resulting version before it goes live again.

Limits

Every workflow carries per-run maximums: the cost a run may incur, the number of steps it may take, the number of model calls, and the number of tool calls. A run that reaches one of them stops rather than continuing past it. They apply whether a run started from a schedule, an inquiry, or a request you typed, and they apply to a preview exactly as they apply to a live run.

Where Charter supplies the model, that is the whole of your model configuration. There is no provider key to paste, no model to choose, no output limit and no token prices to enter. Usage is metered in credits against a plan allowance, and when the allowance is used up, work that needs the model stops and says so rather than continuing on something cheaper. No fallback silently switches the model or loosens the spending policy. What a plan costs has not been settled yet, and this site will say so until it has been.

A workspace that supplies its own model sets those boundaries itself: the provider, the exact model, an output token limit, the current input and output token prices, and a workspace spending limit. Charter's own cost figures are an estimate against those prices; what the provider charges is authoritative. Outside lookups draw from a bounded allowance of their own, with a cache so the same property is not read twice in a day.

A ballpark is a ballpark. With that option on, Charter multiplies the rate you saved by the living area a property data service holds on record for the address. Recorded living area is not measured paintable surface, it is not a site survey, and the figure is labeled a ballpark wherever it appears, never a quote. Above the size you set, the reply carries no figure at all and you get a visit brief instead, and nothing is priced when no living area was found. An estimate rests on a different basis entirely: its quantities come from your own notes and its prices from your notes or your rate card.

What Charter does not do yet

Charter is a bounded product being prepared for a private pilot, and it is more useful to say what is out of scope than to imply it is in. Charter does not currently do these things.

• Send anything to a customer without your approval. Sending automatically below a threshold is a later decision, and it depends on first measuring how often you edit a draft.
• Take a payment, or check whether one arrived. A record becomes paid because you told Charter it was.
• Post accounting entries or move money. A draft number is Charter's own reference for finding a document, not an accounting entry, and collecting payment happens in your own payment system.
• Connect to a CRM, a calendar, or an accounting system. For this work, Charter is the record.
• Book calendar appointments.
• Work from text messages or chat apps. The ways in are your website form and email.
• Prepare, send, or sign contracts.
• Place supplier orders or make purchases.
• Generate original images. It uses the logos and photos you supply.
• Call arbitrary outside services. Tool steps are a small built-in set, and connections come from a maintained catalog.
• Execute generated code. Generated text stays text.
• Publish to a storefront or a social account.

A reviewed document can describe any of these without performing them: a visit brief can list the materials to order, and an estimate can mention a signing step. When a request needs one of them, Charter names the missing capability rather than improvising around it, and you can choose a prepared document as the outcome instead.

The workflow guide walks through the same ground from the owner's seat, with the questions each step asks. If the work you have in mind fits what is described here, tell us about it.