# Meetext

> Forward deployed engineering should scale like software.

Meetext is the forward deployed engineering layer between software companies and the enterprises they sell to. A software company connects its MCP server, OpenAPI document or repository once. Meetext then handles customer-specific deployment, authorization, security review, validation, versioning, health and ongoing operations for every enterprise customer that installs it.

It also carries the vendor's own AI assistant into those customers' workspaces. A customer's staff ask a question in Slack, Microsoft Teams or Google Chat; Meetext resolves which customer they belong to, hands the question to the vendor's assistant along with that customer's own credentials and capabilities, and relays the reply. The model, the prompt and the name on the bot are the vendor's. Conversation history is neither sent nor stored.

The unit Meetext owns is the customer deployment. It is not a workflow automation tool, not an MCP host, not a unified API, not a connector directory, and not an implementation consultancy: it does not compose products with each other, it ships one product into a place somebody else controls.

Today the entry point is deployment infrastructure. As the operational record accumulates it becomes deployment intelligence, and the software FDE is built on top of that. Only the first of those three is shipping.

## Pages

- [Home](https://meetext.xyz): What Meetext does, in the order a first-time reader needs it.
- [About](https://meetext.xyz/about): The argument for why enterprise AI deployment is infrastructure work, who it is for, and what Meetext deliberately is not.
- [AI in customer workspaces](https://meetext.xyz/ai-in-customer-workspaces): How a software vendor's own AI assistant answers their customers' staff inside Slack, Teams or Google Chat, what it is given access to per customer, and what Meetext deliberately never touches.
- [How it works](https://meetext.xyz/how-it-works): The deployment pipeline in seven phases, plus one end-to-end walkthrough of a fictional deployment from signed contract through breakage and recovery.
- [Forward deployed engineering](https://meetext.xyz/forward-deployed-engineering): What the role is, why it does not scale, the eleven things the job consists of, and an explicit split between what Meetext automates today and what is direction.
- [Customer deployments](https://meetext.xyz/customer-deployments): Why every enterprise installation is a versioned object with a state and a history, and why protocol, deployment and capability health are reported separately.
- [Deployment control plane](https://meetext.xyz/deployment-control-plane): The arc from deployment infrastructure to deployment intelligence to the software FDE, and the deployment context document that makes the later stages possible.
- [Integrations](https://meetext.xyz/integrations): Every destination Meetext models, with support status generated from the adapter registry rather than written by hand. Each destination has its own page.
- [Enterprise MCP](https://meetext.xyz/mcp): Why an MCP server is not a deployment: per-customer endpoints, entitlement, frozen tool sets and schema-change approval revocation.
- [OpenAPI to MCP](https://meetext.xyz/openapi-to-mcp): How an OpenAPI document becomes capabilities, classified by risk, and why the conversion is the easy part.
- [Questions](https://meetext.xyz/faq): What a forward deployed engineer is, whether to hire one, what an AI FDE is, how customer deployment works, and how to get through a customer's security review.
- [Terms of service](https://meetext.xyz/terms): Terms covering use of Meetext, including that there is no SLA yet.
- [Privacy policy](https://meetext.xyz/privacy): What is stored, what is deliberately not stored (capability argument values, raw provider messages), and where credentials live.
- [Developers](https://meetext.xyz/developers): The REST API the dashboard itself is a client of, and a plain statement of what is proven and what is not.
- [Security](https://meetext.xyz/security): What is stored and what is not, how credentials are scoped per customer environment, and what the shareable security review contains.
- [Pricing](https://meetext.xyz/pricing): Priced by active customer environment, not by traffic, because the billable unit is the deployment.
- [FAQ](https://meetext.xyz/faq): The questions a technical evaluator asks first.
- [Changelog](https://meetext.xyz/changelog): What shipped, in order, with what each release lets an operator do.

## Documentation

- [Overview](https://meetext.xyz/docs): What Meetext models, the vocabulary the rest of the documentation uses, and where to go next.
- [Quickstart](https://meetext.xyz/docs/quickstart): Connect a source, approve capabilities, create a customer, send an install link, and watch the deployment validate.
- [Sources](https://meetext.xyz/docs/sources): MCP servers, OpenAPI documents and repositories: what gets imported, what gets refused, and why the refusals are shown to you.
- [Capabilities](https://meetext.xyz/docs/capabilities): Deterministic risk classification, the deliberate second approval for writes, and re-approval when a source changes shape.
- [Deployments](https://meetext.xyz/docs/deployments): The nine deployment states, the three health layers and why they stay separate, incidents, and dependency degradation.
- [Hosted MCP endpoint](https://meetext.xyz/docs/mcp): POST /mcp/products/{slug}, one bearer token per customer environment, three protocol versions, four methods.
- [Security model](https://meetext.xyz/docs/security): Schema validation before your backend is reached, auditing by argument name, credential scoping, and the shareable security review.
- [REST API](https://meetext.xyz/docs/api): The resource surface, API keys, authentication, errors and idempotency.

## Questions and answers

Each answer below is self-contained and quotable on its own.

### How do I deploy my AI assistant into my customer's Slack?

You need three things and only one of them is the assistant. An app registered with Slack, Teams or Google Chat and reviewed by them; a way to turn an incoming workspace id into the right customer with the right credentials, which must never be wrong once; and per-customer access to your own product, so the assistant answers as that customer rather than as you. Meetext provides the second and third and carries the message both ways, so what you build is the assistant. Your model, your prompt and your name on the bot, with nothing identifying Meetext to the person asking.

### Can I put my own AI in my customers' workspaces without building a deployment team?

That is what the assistant bridge is for. You point a product at an endpoint you run, and questions asked in a customer's Slack, Teams or Google Chat arrive there with that customer's own credentials and capabilities attached. The parts that are identical for every customer after the first, resolving whose workspace a message came from, running the consent and token lifecycle, scoping access per customer and streaming a reply back without it looking broken, are the product rather than your next quarter.

### Does Meetext see my customers' conversations?

No. A question is sent to your assistant with a stable thread reference, and your assistant keeps its own memory against that reference. The history is not sent to you by Meetext and is not stored by Meetext, which is a stronger statement than a retention policy: there is nothing held to retain. Capability arguments are audited by name and never by value for the same reason.

### What stops my assistant answering one customer with another customer's data?

Two things. A message is answered only when the workspace it came from resolves to exactly one installation; an unknown workspace is ignored and so is an ambiguous one, rather than being resolved by picking the first match. And the access your assistant is given is a per-customer endpoint and token, scoped to a single customer environment, so a call made for one customer cannot list or reach another's capabilities.

### What is a forward deployed engineer?

An engineer who works inside a customer's environment to get a product running there: understanding their systems, configuring the integration, getting through security review, handling identity and permissions, proving it works and keeping it working. Solutions engineer, implementation engineer, customer engineer and post-sales engineer describe substantially the same job. It exists because enterprise software is sold as a product and delivered as a project, and somebody has to close that gap.

### Should I hire a forward deployed engineer?

If you are asking because every enterprise customer needs weeks of engineering before they can use what they bought, a hire will solve it for the next two or three customers and then you will need another one. The work is roughly the same each time: the same OAuth flow, the same security questionnaire, the same validation, the same upgrade, against a different tenant. That part is a software problem. Hire for the judgement work, which is understanding what a customer actually needs, and make the repetition somebody else's infrastructure.

### How much does a forward deployed engineer cost?

Forward deployed engineers are among the most expensive engineers to hire, because the role wants somebody who can write production code and sit in front of a customer's security team in the same week. The larger cost is usually the delay: revenue recognised months after a contract is signed, and senior engineering time spent on the fortieth repetition of a flow rather than on the product.

### What is an AI FDE?

An agent that does the forward deployed engineering job: reading a customer's environment, planning a deployment, configuring it, diagnosing failures and repairing them. Nobody has finished building one. Meetext is not an AI FDE today and does not claim to be; it is the deployment control plane an AI FDE would have to operate through, because an agent reasoning over a pile of API responses will be confidently wrong, and one reasoning over an append-only deployment record with provenance on every inference can be checked.

### Is this the same as implementation consulting?

No. A consultancy sells people and bills for their time, so a faster deployment is worse for them. Meetext is software priced per customer environment, so a faster deployment is the product working. There is also nobody to schedule: the repeatable parts run without a human, and the parts that still need judgement arrive with the context to make it quickly.

### How do I deploy my product into a customer's Slack, Microsoft 365 or Salesforce?

Connect your product to Meetext once, as an MCP server, an OpenAPI document or a repository. Choose which operations customers should get. Meetext generates the deployment package, produces a security review artifact, and gives you one installation link per customer. The customer's administrator approves it in their own workspace, Meetext runs the OAuth flow, stores the grant scoped to that one customer, executes a real capability to prove it works, and then monitors it.

### Do I have to have an MCP server already?

No. An OpenAPI document works, and so does a repository. Meetext scans FastAPI, Flask, Django, Next.js and Express for routes and service functions. Whichever you connect normalises into the same internal capability format, so every destination behaves identically.

### How long does a customer deployment take with Meetext?

The parts Meetext owns take minutes: generating the package, issuing the link, running authorization, validating, and starting to monitor. What Meetext cannot compress is the customer's own calendar. If their administrator takes nine days to approve admin consent, the deployment takes nine days, and Meetext reports it as waiting on that administrator rather than as a failure or as your problem.

### What happens when my API changes?

Rediscovery detects the difference and revokes approval for any capability whose contract changed, so an approved operation that quietly became a different operation cannot ship. Existing customer installations keep serving the package they were given: publishing a new version does not move an existing customer until somebody deliberately moves them.

### Can I drive all of this from CI?

Yes. The dashboard is a client of the same REST API you get, every operation of it, authenticated with an API key. Create products, connect sources, approve capabilities, create customer environments and trigger validations from your own pipeline.

### Does Meetext see my customers' data?

Capability results pass through the hosted endpoint in memory to reach the destination. They are not stored. Execution is audited by argument name only and never by value, so Meetext records that a search happened and not what was searched for. Credentials live in a secret manager under a name scoped to a single customer environment and are never shared between two customers.

### How do I get through my customer's security review?

Meetext generates a review artifact for each customer naming the capabilities being exposed, the permission each one needs and why, where credentials live, and what data crosses which boundary. Every claim is tagged with who is standing behind it, so what Meetext observed is distinguishable from what your company asserted. Approval is recorded against the exact snapshot the customer saw, which means an approval cannot silently start covering whatever you published next.

### Whose application does the customer see on the consent screen?

Yours. Each vendor registers their own Slack app, Entra application, Connected App or equivalent, and those credentials are stored per deployment target. One shared application could not represent two companies to a security reviewer, so Meetext does not try.

### Which enterprise systems can Meetext deploy into?

Slack, Microsoft 365, Google Workspace, Salesforce, ServiceNow, Atlassian and HubSpot. All seven are in preview: the adapters are complete and covered end to end against provider simulators, and none has yet run against a real provider account. Meetext will not describe a destination as available until every part of the deployment lifecycle has actually run against the real provider, and a test refuses the claim without dated evidence.

### Can you add a destination that is not on the list?

A destination is seven interface methods and one registry line, and contract tests run against every registered adapter so a new one is held to the same standard as the existing ones. The honest constraint is not the code, it is that each destination is a real OAuth model, permission system and set of failure modes that has to be understood before it is worth shipping. Tell us which one and how many customers, and that is how the next one gets picked.

### What counts as an active customer environment?

One customer, one product, one destination. It counts while it is installed. Disconnected environments do not count, and calling your capabilities more often never changes the bill.

## Technical facts

- The hosted MCP endpoint is POST /mcp/products/{product_slug} with a bearer token issued per customer environment.
- Supported MCP protocol versions: 2025-06-18, 2025-03-26, 2024-11-05. Transport is Streamable HTTP.
- Destination support, derived from implementation and proof: Atlassian (preview), Google Workspace (preview), HubSpot (preview), Microsoft 365 (preview), Salesforce (preview), ServiceNow (preview), Slack (preview).
- No destination is Available. Three adapters are complete and covered end to end against a provider simulator; none has yet run against a real Slack workspace, Entra tenant or Google Workspace domain. Available requires real-provider proof for every part of the deployment lifecycle, and a test refuses the claim without dated evidence.
- The assistant bridge relays a question from Slack, Microsoft Teams or Google Chat to an endpoint the vendor runs, and relays the reply back into the same thread. Streaming and single replies are both supported; a streamed answer is posted on the first chunk and the same message is edited as it grows.
- A question sent to a vendor's assistant carries that customer's own MCP endpoint and bearer token, so the assistant acts inside the customer's workspace with the customer's credentials, bounded by the frozen deployment package and that customer's entitlements.
- Conversation history is never sent to the vendor and never stored by Meetext. A stable thread reference is sent instead, and the vendor's assistant keeps its own memory against it.
- A message is answered only when the originating workspace resolves to exactly one installation. An unknown workspace is ignored and so is an ambiguous one, because answering there would mean answering one customer's question against another customer's data.
- A vendor without an assistant can use a model Meetext runs. It is given the same per-customer endpoint as its tools, so it answers only from capabilities the vendor approved and the customer is entitled to.
- The assistant bridge is complete and covered end to end against a provider simulator. It has not yet carried a question in a real Slack workspace, Teams tenant or Google Chat space.
- A failing tool returns a result with isError set, never a JSON-RPC error. The distinction decides whether a model retries.
- Health is three separate layers: protocol (can a client connect and list tools), deployment (is this customer's installation authorized and current), capability (would a call actually execute). They can disagree, and collapsing them is the failure this product exists to prevent.
- Capability arguments are audited by name and never by value. Results transit in memory and are not stored.
- Credentials live in Secret Manager under a name scoped to a single customer environment, never in the database.
- Write and delete capabilities require a deliberate second approval, and the approval is revoked if the source later changes that operation's shape.

## Recent releases

- 23 August 2026, Your AI, in your customer's workspace: A vendor's own assistant now answers their customers' staff in Slack, Teams or Google Chat, with that customer's own credentials and capabilities. Meetext carries the question and the reply and touches nothing else.
- 20 August 2026, Seven destinations, and a rule about what counts as shipped: Salesforce, ServiceNow, Atlassian and HubSpot adapters, and a proof registry that decides what the website is allowed to claim about any of them.
- 16 August 2026, Firestore end to end: The store moved to Firestore completely. Every guarantee a relational schema used to give for free is now something explicit that a test proves.