Capabilities | Charter

Available is not the same as enabledEvery capability on this page exists in the product today. Which of them your workspace uses depends on the switches you turn on, your answers and your connections, and we confirm each one with you during the pilot. Charter is being prepared for a bounded, invite-only pilot. Live checks with each provider, covering mail, mailboxes, models and property data, are recorded per workspace, and none has been completed so far.

The switch path

Most owners meet Charter as a small set of switches. You answer four questions, point your website form at an address or connect your mailbox, read a replay of your own recent inquiries, and turn on one switch. Charter supplies the model, so there is no provider account to open and no workflow to draw. Everything in this section is what that path is made of.

For each capability, the permission boundary is what Charter enforces, not a preference, and the limitation is the honest edge of what the capability does.

Account and workspace setup

Inputs: Your name, email and password, and the name of your business.
Result: A separate owner workspace. Setup can be saved and revisited, and it ends with your answers stored and nothing switched on.
Permission boundary: Account creation is all or nothing. Workspace access is bound to the signed-in session. Setup never activates work. Creating the workspace is a self-service step inside the pilot; access to the pilot itself is arranged with each participating owner.
Example: A painter creates a workspace, answers four questions, and reads a replay before deciding anything.
Current limitation: Charter does not send email verification or password reset messages; if you lose access to your account, contact support. Setup creates an owner workspace. Team members join later through owner-created invitation links from the Team page; invitation emails are not sent, so the owner shares the link.

Setup in four answers

Inputs: Where you work, the services you offer, how customers book time with you, and an optional ballpark rate. Quotes and invoices add a plain-text rate card and a tax percentage.
Result: Your answers are saved once and read by every switch you turn on, so a switch is configured by answering rather than by drawing a workflow.
Permission boundary: Owner only. The answers are workspace settings, not secrets, and the work Charter does reads them by name. Your rate, your rate card and your tax percentage are kept out of the background material a model sees, and reach a calculation only where the work explicitly asks for them.
Example: A painter enters three towns, interior and exterior painting, a booking link, and a rate per square foot.
Current limitation: The answers are your own words. Charter does not geocode your area, does not match your services against a catalogue, and does not check that what you wrote is complete. A rate card edit takes effect the next time the switch that uses it is saved, so turn that switch off and on after changing it.

Charter-supplied model, metered in credits

Inputs: Nothing. There is no provider key to paste, no token prices to enter and no model to choose.
Result: Every step that reads or writes text runs on a model Charter supplies and operates. Usage is metered in credits against your plan allowance, and the per-run caps on steps, model calls, tool calls and spend still apply.
Permission boundary: The provider credential stays with Charter and never reaches a prompt, a run record or your browser. A workspace on Charter-supplied models cannot raise its own allowance, and the model settings are hidden from it. Charter reserves before a call and settles after it; a charge whose outcome is uncertain is reconciled by Charter, not by you.
Example: A replay, and every draft after it, runs without the owner opening an account with a model provider.
Current limitation: Pricing for managed model access, and for each switch, is an open decision. There is no published price and no self-serve plan. Credits are granted by Charter. No paid model call has been made so far, so model quality, refusal behavior and provider access are untested.

Email intake, with or without a connection

Inputs: The notification email your website form already sends, either forwarded to an address Charter gives your workspace or read from a connected Gmail or Microsoft 365 mailbox. An optional subject filter narrows what counts.
Result: Each message starts one run for each switch that wants it. A duplicate delivery of the same message starts nothing. Mail that arrived before you turned the switch on is left alone.
Permission boundary: The forwarding address needs no account connection and carries no outgoing permission: mail arriving there lets Charter read that message, nothing more. A connected mailbox is used only within the switch you turned on.
Example: A form notification lands at the Charter address and a reply is drafted for review, with no mailbox ever connected.
Current limitation: Sender identity is not authenticated. Charter trusts the addresses a mail provider presents and does not evaluate sender-authentication results, so the forwarding address should be treated like a private link. A message with an empty or very long body is not accepted and is retried on a widening delay. No live mail service round trip and no live mailbox connection has been recorded so far.

Replay and preview

Inputs: Your own recent form emails, from the forwarding address or from a connected mailbox, with an optional subject filter and a count.
Result: Charter shows you what it would have written for each one, beside the original, before any switch is on. Each draft carries what was extracted, whether Charter read the message as an inquiry, and whether it qualified.
Permission boundary: A preview runs the model steps for real and charges the credits they use, and substitutes every external effect: no property read, no external action, no approval request, no wait, and no message to you or to a customer. A preview deliberately does not satisfy the requirement to simulate a version before activating it, so a replay cannot turn anything on by itself.
Example: Ten recent inquiries replayed in a few minutes, read side by side, then one switch turned on.
Current limitation: A replay uses credits. The balance is checked before the runs are created, so a run started elsewhere at the same moment can consume it first and leave the last previews blocked. A preview reads no property record, so a preview draft never carries a ballpark. Every preview is labeled as a preview wherever it appears, and a message the workflow's own inputs reject is reported as skipped rather than replaced by an older one.

Inquiry qualification

Inputs: The postal code or city and the requested service read out of the message, checked against the service area and the services you entered.
Result: An in-area result naming the area it matched, a supported-service result naming the service it matched, and the reasons when it does not qualify. The work branches on that result, so an inquiry you cannot take finishes with a polite decline draft for you to review rather than ending silently.
Permission boundary: A deterministic check. It makes no model call, reads nothing beyond your own answers and the extracted fields, and behaves identically in a simulation. An empty answer is reported as not configured and never declines an inquiry.
Example: A request for a service you do not offer becomes a short clarifying reply instead of a quote.
Current limitation: This is keyword and postal-code matching for routing to review, not a guarantee that a job is in range or that you offer it. A postal code Charter cannot read in a standard form is unknown rather than out of area. What the check sees depends on what was extracted from a customer's own message.

Approval by email

Inputs: A pending review and the exact draft it is bound to, including any attachment.
Result: Charter emails you the draft. Reply YES, APPROVE or OK to send it, NO or REJECT to drop it, or return a corrected version inside the delimited block the email shows you. A correction replaces the draft, invalidates the earlier approval, and asks you again.
Permission boundary: The reply must come from the address on your Charter account and carry the token Charter issued for that review. Approval is bound to the exact values you saw: a changed price, recipient or attachment invalidates it. Approving by email is the same decision as approving in Charter, and you can turn the emails off and review in Charter instead.
Example: A painter approves a reply from a phone, on site, between jobs.
Current limitation: Sender identity is not authenticated. Sender-authentication results are neither parsed nor enforced, so the reply address should be treated like a private link. A corrected version works for a drafted document or message; a review of an action through a connected account asks for YES or NO, or an edit in Charter. Replies are collected on a polling cycle, not the instant they arrive.

Switches

Inputs: The switch you want and its options: where the work comes in, how the result is delivered, and a few numbers such as a follow-up interval.
Result: Turning a switch on saves the workflow version, runs its required simulation and activates it, in one sequence Charter checks at every step. Turning it off pauses it. Your options are kept, so turning it on again rebuilds the same thing, and changing one saves and simulates a new version.
Permission boundary: Owner only. The control grants nothing: Charter still requires a completed simulation of that exact version before activation, and refuses to turn a switch on without a usable model or a required answer. Every external send in every switch starts in review.
Example: Reply to inquiries turned on after a replay, then turned off for a week in August.
Current limitation: A simulation shows that the steps fit together with sample text. It is not evidence of model quality, live permissions or delivery. If the linked workflow is changed elsewhere while a switch is settling, the switch waits until you turn it off and on again. Turning a switch off does not cancel a simulation already running; it finishes and changes nothing.

Reply to inquiries

Inputs: An inquiry email and your four answers.
Result: The customer's details and request are extracted, the inquiry is qualified, and a reply is drafted in your words using your booking method or link. After your approval, Charter either delivers the approved draft to you to send, or sends it from your connected mailbox and follows up once, after a delay you choose, unless the customer has already replied.
Permission boundary: Nothing reaches a customer without your approval, and the work permits no automatic action. Customer text arrives as information, never as instructions, and cannot change what Charter may do.
Example: A form submission on Tuesday becomes an approved reply the same afternoon, with one follow-up three days later if nobody answers.
Current limitation: The draft never states a price, a date or an availability you did not supply. That instruction has been exercised against substitute models only, never against a live model. A message Charter does not read as an inquiry finishes with no draft. Provider acceptance of a send is acceptance, not delivery, and email providers offer no universal exactly-once guarantee.

Add a ballpark

Inputs: A full address in the message, the ballpark rate you entered, and the size above which you want to look before anything is attached.
Result: A property data service is asked for the recorded living area. At or below your threshold the reply carries a clearly labeled ballpark. Above it you get a visit brief instead, and the reply carries no figure.
Permission boundary: The property credential stays with Charter, behind a bounded monthly request allowance. An address that is not complete returns not found without a request. Nothing is priced without a confirmed living area, and Charter never invents a rate.
Example: A small interior job comes back with a labeled ballpark; a large house comes back as a visit brief.
Current limitation: Living area is not measured paintable surface. A ballpark is a ballpark, never a quote, and it is labeled that way everywhere it appears. Record coverage and accuracy for real addresses are unknown, because no live property read has been recorded so far. A preview shows no ballpark at all.

Quote from visit notes

Inputs: Your notes after a visit, typed into Charter, forwarded to the Charter address, or sent from a connected mailbox, plus your rate card and tax percentage.
Result: The scope and quantities in your notes become line items, priced only from your notes or your rate card, with deterministic totals and tax, a numbered draft estimate and a PDF. After your approval it comes back to you with the PDF attached, or goes to the customer from your connected mailbox after a second review of that send.
Permission boundary: Every figure is calculated, never generated. A line counts as priced only when a plain quantity and a plain price are present, and Charter never derives a price from another line, from an area, from a total, or from its own knowledge.
Example: Notes covering three rooms and a hallway become a draft estimate with a line for each and a total.
Current limitation: Charter prices what your notes and your rate card cover and stops for the rest: a missing fact produces a note to you naming what is missing, and no estimate. A price written into the notes themselves is refused rather than used. A rate card edit reaches this switch only after it is saved again.

Invoice from an accepted estimate

Inputs: The job, named by draft number or customer, any extra work you state in full, and your payment term in days.
Result: Charter finds the estimate in your record book, copies its lines, its customer and its tax without re-rating anything, prepares a numbered draft invoice with a due date counted from the day it was prepared, and links the two records.
Permission boundary: Exactly one matching estimate is required; several matches, or none, produce a note to you and no invoice. The source estimate is marked accepted only in the delivery that follows your approval, so a draft you reject leaves the estimate exactly as it was.
Example: Naming the Whitfield job finds its accepted estimate and prepares the invoice for review.
Current limitation: A draft number is not accounting issuance. Charter posts nothing to an accounting system, issues no invoice, takes no payment and records none. Extra work needs a stated quantity and a plain price, or the run stops and tells you rather than guessing.

The daily chase

Inputs: How long a sent estimate may stay quiet, how long a sent invoice may, and how many reminders you want at most.
Result: Once a day Charter reads your record book for quiet estimates and unpaid invoices past your interval, records the reminder, and drafts it for your review. After your maximum it hands the document back to you once and leaves it alone.
Permission boundary: Every reminder is reviewed before it goes anywhere. A reminder stops when a reply is seen in the conversation, or when you have recorded a status. A reminder restates no price, total, quantity or date, adds no new deadline, discount, late fee or collection step, and asks for no payment details.
Example: Two quiet quotes and one unpaid invoice arrive as three drafts on a Tuesday morning.
Current limitation: A reminder is counted when Charter prepares it, so one you reject still counts towards handing the document back. Charter never marks anything paid by itself; marking a document paid records what you told it. A single run bounds its own work and leaves the rest for the next day, so a long backlog clears over several days.

The record book

Inputs: An estimate or an invoice that a live run produced.
Result: Each one is recorded with its own draft number for your workspace, the customer, the total, and a status you move through draft, sent, accepted, declined, paid and void, with the date of each step and the PDF. You read it in Charter beside the rest of your work.
Permission boundary: Only a live run records a document; a simulation and a preview record nothing and consume no number. You move the status. A workflow marks a document sent when a delivery that carried it actually went out, and accepts a source estimate only when the invoice built from it was approved and delivered. Paid and void are final.
Example: A season of estimates and invoices, with the two that are still unanswered visible at a glance.
Current limitation: A draft number is Charter's own reference for finding and discussing a document, not accounting issuance, and every surface that shows one says so. When Charter hands a document to you rather than sending it, the record reads as handed to you: only you know whether it went anywhere. Marking a document paid records what you said happened; Charter never checks whether anything was paid.

Record lookup

Inputs: A draft number, a customer name or email address, a kind, a status, an age, or how recently a reminder went out.
Result: Your own prior estimates and invoices, read back to you or to the switch that needs them. This is how invoicing finds an accepted estimate and how the chase finds what has gone quiet.
Permission boundary: Your workspace only. What a workflow may ask for is bounded more tightly than your own listing. A simulation returns one clearly labeled sample and opens nothing.
Example: The invoice switch finds the one accepted estimate for a customer, and refuses to choose between two.
Current limitation: It reads what Charter recorded, which is the documents Charter's own runs produced; work you did elsewhere is not in it. Records made before Charter began storing a customer address do not match a search by address.

How intake, sending and receipts work is described in the connections guide.

The configurable tier

The same product, with everything exposed. Chat to build, Studio, the connector catalog and your own model configuration remain available to operators and to owners who ask for them, and they are what a business that no switch fits starts from. The capabilities below serve a painting company, a photographer and a clothing retailer with different facts, templates and permissions.

Assisted setup and chat to build

Inputs: A plain-language outcome and your answers to the clarifying questions.
Result: A reviewable draft workflow built from supported steps. Guided setup from a template is the default and the fallback, and it makes no model charge.
Permission boundary: Setup cannot execute a customer-facing action and cannot activate itself. A message typed during setup grants no authority.
Example: An owner describes a response-and-follow-up routine that no switch covers.
Current limitation: This is not part of the switch path; an owner on switches never meets it unless they ask. Model-assisted interpretation needs a model configuration with token prices and a spending limit in this tier, and it can incur a real charge. Anything Charter cannot do stays visible as unsupported rather than being smoothed over.

Owner-supplied model configuration

Inputs: A provider account key, the model, its token prices, an output limit, and a workspace spending limit.
Result: Model steps dispatch on your own provider account, with the spend reserved before the call and settled after it, per-run caps on steps, model calls, tool calls and spend, and a recovery path for a charge whose outcome is uncertain.
Permission boundary: The key is held encrypted, never reaches a prompt, a run record or your browser, and is used only by your workspace. A workspace on Charter-supplied models does not see these settings.
Example: An operator, or an owner who asks for it, runs Charter on their own provider account.
Current limitation: The prices you enter are what Charter reserves and settles against; Charter does not read your provider's bill or its billing period. No live model call has been recorded so far.

Manual work

Inputs: Your request and any named facts.
Result: A durable run you can inspect while it moves, and pause, resume or cancel at any point.
Permission boundary: The workspace owner, within the limits configured on the workflow.
Example: A painter pastes customer notes and asks for a response.
Current limitation: Live text generation needs a model: your own configuration in this tier, or the one Charter supplies on the switch path.

Scheduled work

Inputs: A repeat interval and an activated workflow.
Result: A run starts at each scheduled interval, and every run is recorded.
Permission boundary: Owner activation, the workflow's rules and its budget.
Example: The daily chase, or weekly campaign preparation for a retailer.
Current limitation: Pausing the schedule stops new starts. A run already in progress is controlled separately with its own pause, resume and cancel. A new interval starts a run whether or not the previous one is still waiting for approvals.

External events

Inputs: A signed request with a timestamp, a stable event ID, and the fields the workflow maps to its inputs.
Result: The activated workflow starts once per event. A duplicate delivery of the same event starts nothing.
Permission boundary: Authentication of the signature and a replay window. An incoming event carries no outgoing permission.
Example: A form that can sign its requests feeds an inquiry workflow without a CRM in between.
Current limitation: The sending service must implement the documented signing contract. Website builders generally cannot sign a request, which is why forwarded email, not a signed webhook, is the intake path on the switch path.

Source material

Inputs: Text, Markdown, CSV, readable PDF, PNG and JPEG files.
Result: Charter reads the supplied text, attaches your existing brand images to output, and keeps authorized references to the files.
Permission boundary: Upload and download require an authenticated workspace session.
Example: A retailer provides collection details and product photos.
Current limitation: Files are bounded in size. Charter does not generate original images, execute code, or promise general reading of scanned documents. Uploaded content is information, not instructions.

Relevant context

Inputs: A query or a work item ID, plus an authorized connection.
Result: Aether knowledge or Scoped work, returned with its sources.
Permission boundary: The identity bound to the connection and the workspace or knowledge area it may reach.
Example: Find a customer's approved finish before drafting the reply.
Current limitation: Retained facts may be stale. Checking the live source is a separate step, not an assumption. Aether and Scoped are neither presented nor set up for a workspace on the switch path.

Content creation

Inputs: Explicit instructions, facts, retrieved context and brand assets.
Result: Editable generated Markdown, and branded HTML or PDF downloads.
Permission boundary: The model and budget in force. Producing a document does not publish it anywhere.
Example: A cover document for a photographer's proposal.
Current limitation: Charter does not invent prices, commitments, testimonials or portfolio work. A missing fact is left as a visible gap for you to fill.

Property lookup and quote calculation

Inputs: A full address, your own rate, the scope, and a review threshold.
Result: A property record lookup, a deterministic living-area estimate, an editable quote document with a PDF, and a review step when the threshold is crossed.
Permission boundary: The property credential stays with Charter, behind a bounded monthly request allowance. Live quotes require a saved workflow version, a completed simulation and explicit enabling.
Example: A painter asks for another property quote inside an active workflow conversation.
Current limitation: Living area is not measured paintable surface. Charter never invents a rate. The calculation makes no model call, sends no email, issues no invoice and makes no binding commitment. On the switch path the same read sits behind the ballpark option instead.

Email response

Inputs: Recipient, subject, reviewed text and optional attachments.
Result: A send through Gmail or Microsoft 365, with the provider's outcome recorded on the run.
Permission boundary: Review by default. Only a narrowly permitted exact action sends without a review.
Example: An owner-approved acknowledgment of a new inquiry.
Current limitation: Provider acceptance is not delivery, and email providers do not guarantee exactly-once sending. No live check with a real Gmail or Microsoft 365 account, covering authorization and an actual send, has been recorded so far.

Follow-up

Inputs: A conversation ID, the recorded send time, a delay and a response rule.
Result: Durable waiting, a reply check, then either a permitted follow-up or suppression of the reminder.
Permission boundary: The same email scope and workflow authority as the original send.
Example: Stop the reminder when the homeowner replies.
Current limitation: Reply checks are asynchronous. The current state is rechecked at dispatch time, which is not guaranteed to be instant. A reply that arrives between the review and the dispatch stops that one send, and the rest of the run carries on.

Work handoff

Inputs: A reviewed brief and a Scoped destination.
Result: Create a work item, publish a comment, or apply a version-checked update.
Permission boundary: The Scoped identity and workspace you connected. Every change is version-checked and receipted by Scoped.
Example: Create photography preparation tasks for an upcoming shoot.
Current limitation: A plan that mentions booking, purchasing or invoicing does not execute those transactions. Scoped is not set up for a workspace on the switch path.

Knowledge retention

Inputs: Approved text, the customer or project it belongs to, and its source or provenance.
Result: Knowledge retained in Aether with a durable receipt.
Permission boundary: The Aether identity and knowledge area you connected; every retained fact is receipted by Aether.
Example: Keep an approved color-selection decision for a customer.
Current limitation: Generated claims are not automatically approved knowledge. A person approves what is retained. Aether is not set up for a workspace on the switch path.

Conversation execution and Studio

Inputs: A saved conversation or workflow, explicit controls, or a direct quote request to an active linked painting workflow.
Result: Search and reopen conversations, start and inspect quote runs, approve a review, and edit triggers, tools, conditions and specialist instructions in Studio.
Permission boundary: Charter enforces the saved revision, activation, configured prerequisites, limits and action permissions. A message typed during setup cannot grant authority.
Example: Review properties over 3,000 living square feet and finish smaller quote runs automatically.
Current limitation: Studio and chat to build stay available to operators and to owners who ask for them. They are not part of the switch path, and an owner on switches is never asked to draw a workflow. A direct quote request is dispatched only when no setup question is pending. Specialist generation steps use the model in force; there is no unrestricted agent delegation and no arbitrary code.

Simulation

Inputs: A saved workflow version and sample input.
Result: A saved run in which model results and external effects are substituted and labeled as such.
Permission boundary: Explicit simulation mode. Nothing is sent, spent or written in a connected service; the simulated run and its documents are still recorded in your workspace, and no document number is consumed. A simulation is the only mode that satisfies the requirement to simulate a version before activating it.
Example: Test the painting, retail and photography examples before activating anything.
Current limitation: A simulation is not evidence of model quality, live permissions, delivery, or compatibility with a connected service. Because every model result is substituted, it cannot show you the text Charter would actually write; that is what a preview is for.

Review and recovery

Inputs: A document revision, a pending approval, or a recorded action and its receipt.
Result: Approve or reject, revise a draft, and recheck or recover uncertain work.
Permission boundary: Approval is bound to the reviewed values. Charter rechecks authority before acting.
Example: A proposal changes before publication, so the earlier approval expires with it.
Current limitation: Finished results stay attributable. A completed action record is never silently rewritten.

Inbox

Inputs: Charter runs, pending reviews, saved deliverables, your document records, and connected email accounts.
Result: Search, filter and page through all workspace work; inspect documents; download PDFs; approve or reject exact reviewed content; read the record book and move a document's status; choose Charter, your documents or a connected inbox as the source.
Permission boundary: Your signed-in workspace session. Approval is bound to the exact reviewed content, the same rule as everywhere else in Charter. Moving a document's status is an owner decision; another member reads the record without the controls. Selecting an account grants no new permission.
Example: Review a generated estimate alongside the rest of the week's work.
Current limitation: The Inbox shows the state and controls of connected email accounts. It does not browse a mailbox or merge email messages into one list.

Building and activating a workflow by hand is covered in the workflow guide.

Supported run steps

Every workflow is composed from a short, fixed list of step types, whether you drew it or a switch built it. You configure the workflow; model steps operate inside it. Generated text is never executed as application code.

Input: The request and named facts a run starts with, declared and checked on every entry point.
Context: Retrieval from an authorized connection, such as Aether knowledge or a Scoped work item.
Generate: A model step that produces editable text within the model and budget in force.
Extract: A single structured extraction of named inputs from supplied text. An invalid extraction stops the steps that depend on it.
Tool: One of the built-in tool actions, from a short fixed list.
Branch: A condition on recorded values that chooses the next step.
Approval: A review step bound to the exact values shown to the reviewer, offered in Charter and by email.
Action: An external action through a connection, such as a send or a handoff, with a receipt.
Wait: A durable delay that survives restarts.
Check reply: A look at the connected mailbox for a reply to a recorded send.
Finish: Records the outcome and closes the run.

Run modes

A run happens in one of three modes. A live run does the work. A simulation substitutes every model result and every external effect, and it is the only mode that satisfies the requirement to simulate a version before activating it. A preview runs the model steps for real and charges the credits they use, while substituting property reads, external actions, approvals, waits and messages to you. That is what lets a replay show you real drafts without anyone hearing from Charter, and it is deliberately not accepted in place of a simulation.

Tools and conditions

Built-in tool actions are a short, fixed list: a property record lookup and the ballpark calculation; deterministic service estimate and invoice draft calculations; the inquiry qualification check; two checks that decide whether visit notes are complete enough to price and map them onto the estimate contract; reading back one of your own saved documents; converting an accepted estimate into an invoice draft; searching your record book; recording that a reminder was prepared, a reply was seen, or a document was handed back; and delivering a draft to you by email with the document attached. A workflow cannot call an arbitrary outgoing API. Numeric conditions compare recorded values and reject a missing or invalid measurement instead of guessing, and financial arithmetic is always calculated, never generated.

Property lookups reserve from a monthly request allowance before dispatch, fifty by default and configurable downward. That allowance counts Charter's own requests; it cannot see use of the same credential elsewhere or the provider's billing cycle. Confirmed property data is reused within the same workspace for 24 hours. An uncertain read is kept and not automatically repeated, and a simulation uses substitute data and consumes no request.

Starters and templates

The starter library covers the five switches and the templates behind them: inquiry replies with follow-up, quotes from visit notes, invoices from an accepted estimate, the daily chase, property quotes, work handoff, branded material, sourced answers, request intake, service estimates, invoice drafts, work plans, customer preparation and completion summaries. The property template applies your rate to the recorded living area, then requires review strictly above 3,000 square feet by default. Exactly 3,000 or less follows the completion branch. Both the threshold and the rate are editable in Studio. New industry examples compose these capabilities before any new runtime behavior is added.

Outside the product

These are outside the current product. A reviewed plan or document may describe one of these activities without claiming to perform it, and a run record will never show it as done.

Original images: Charter places your existing logos and photos. It does not generate new images.
Arbitrary outbound APIs: Actions go through supported connections and built-in tools only.
Generated-code execution: Generated text is never run as application code.
General agent delegation: Specialist steps run inside a workflow. There is no open-ended delegation.
Calendar booking: A draft can carry your booking link or propose times. Charter does not book them, and it reads no calendar.
Contracts and signatures: Documents can be prepared for signing elsewhere, not signed.
Supplier purchases: A work plan can list what to buy. Charter does not buy it.
Accounting and payments: Charter numbers and tracks its own draft estimates and invoices. It issues nothing into an accounting system, takes no payment details, moves no money and records no payment.
Storefront and social publishing: Branded material is produced for download, not posted.
Messaging apps and browser control: Charter works over email. Telegram, WhatsApp and Slack are not intake or transport, and Charter does not drive a browser on your behalf.
Enterprise administration: Centralized administration across many workspaces is not part of the product.
Installing Charter yourself: Charter is not offered as software to install in your own cloud or on your own servers.

If the work you have in mind depends on one of these, say so in a pilot request. We will tell you plainly whether Charter fits.

The switch path

Account and workspace setup

Setup in four answers

Charter-supplied model, metered in credits

Email intake, with or without a connection

Replay and preview

Inquiry qualification

Approval by email

Switches

Reply to inquiries

Add a ballpark

Quote from visit notes

Invoice from an accepted estimate

The daily chase

The record book

Record lookup

The configurable tier

Assisted setup and chat to build

Owner-supplied model configuration

Manual work

Scheduled work

External events

Source material

Relevant context

Content creation

Property lookup and quote calculation

Email response

Follow-up

Work handoff

Knowledge retention

Conversation execution and Studio

Simulation

Review and recovery

Inbox

Supported run steps

Run modes

Tools and conditions

Starters and templates

Outside the product

Read next