# Meetext > Forward Deployed Engineering as a Service. Ship your AI, MCP server, or API into every customer workspace, then find what they still cannot do and build it. Meetext is AI-native forward deployed engineering software. Connect MCP, OpenAPI, a repository or a customer database, deploy into enterprise workspaces, and turn customer requests into changes verified against their agreed criteria. The buyer is a software vendor selling to enterprises. Each customer deployment has its own approved capabilities, entitlements, credentials, vocabulary, version, security review and validation evidence. Meetext classifies capability risk deterministically and requires explicit approval before exposing operations that change data. Meetext observes unmet requests and failing customer cases, groups related gaps across customers, and routes each gap to the person or system that can resolve it. For repository changes it can draft code, validate it, attempt a repair and open a pull request with the customer evidence attached. A gap is not closed just because code was written: the customer's agreed case must pass. Customer-written acceptance criteria are frozen in engagement briefs and rerun on publish. Verification checks the capability trace first, an optional grading rubric second, and brings uncertain judgments to a person. Without a configured grader, an expectation that requires grading is inconclusive, never automatically passed. The Meetext Agent works through the same actions and permission checks as the dashboard. It can prepare deployments, share security reviews, draft emails to registered contacts and run scheduled checks. A dashboard change is proposed for confirmation before it runs. The separate engineering loop starts at Observe and can be given Assist, Act or Autonomous authority; it never exceeds that authority or acts on an inference as if it were an observed fact. Meetext is not a general-purpose workflow builder or a replacement for every human engineering decision. Its unit is the customer deployment, and its engineering work is grounded in that customer's permissions, operational record and agreed criteria. ## Sources - MCP server: Discover tools from a Streamable HTTP MCP endpoint. - OpenAPI document: Import OpenAPI 3 JSON or YAML by URL or upload, with one capability per operation. - Repository: Scan supported application routes and promote selected candidates into capabilities. - Customer database: Expose approved database capabilities under a customer-specific connection and access policy, on eligible plans. ## Assistant modes Customer deployments can use your own AI, Meetext-hosted AI, or capabilities without an assistant. With your own AI, Meetext relays a workspace question to the endpoint you run with that customer's MCP endpoint and bearer token. The bridge sends a stable thread reference, not conversation history; your assistant manages its own memory. With Meetext-hosted AI, the model receives the same customer-scoped capabilities, bounded by approvals and entitlements. Customer masking, hosted-model budgets and pause controls apply. Without an assistant, customers use the approved capabilities through their destination's supported interface. The Meetext Agent is distinct from the assistant answering your customers' product questions: it performs deployment and operational work through dashboard permissions and confirmation cards. Its saved conversations are separate from the vendor assistant bridge. Slack and Google Chat support customer-scoped assistant conversations. Microsoft Teams onboarding is temporarily in Preview. ## Pages - [Home](https://www.meetext.xyz): What Meetext does, in the order a first-time reader needs it. - [About](https://www.meetext.xyz/about): AI-native forward deployed engineering for software vendors: customer deployments, evidence-backed changes, and the work that stays with people. - [The Meetext Agent](https://www.meetext.xyz/agent): The AI agent in the dashboard: what you can ask it to do, how a request runs one confirmed step at a time, email and scheduled checks, per-person permissions, and the guardrails decided in code. - [AI in customer workspaces](https://www.meetext.xyz/ai-in-customer-workspaces): Your own AI, Meetext-hosted AI or no assistant: customer-scoped capabilities inside workspaces and the permissions that bound each mode. - [How it works](https://www.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://www.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://www.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://www.meetext.xyz/deployment-control-plane): The operational foundation of the AI FDE: versioned deployments, customer context, incident evidence and permission-aware engineering actions. - [Integrations](https://www.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://www.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://www.meetext.xyz/openapi-to-mcp): How an OpenAPI document becomes capabilities, classified by risk, and why the conversion is the easy part. - [Questions](https://www.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://www.meetext.xyz/terms): Terms covering use of Meetext, including that there is no SLA yet. - [Privacy policy](https://www.meetext.xyz/privacy): What is stored, what is deliberately not stored (capability argument values, raw provider messages), and where credentials live. - [Developers](https://www.meetext.xyz/developers): The REST API used by the dashboard, with the deployment lifecycle available for product and pipeline automation. - [Security](https://www.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://www.meetext.xyz/pricing): Every Meetext plan is free during launch. Compare customer and environment limits, with published monthly and annual rates for when billing begins. - [Changelog](https://www.meetext.xyz/changelog): What shipped, in order, with what each release lets an operator do. ## Documentation - [Overview](https://www.meetext.xyz/docs): What Meetext models, the vocabulary the rest of the documentation uses, and where to go next. - [Quickstart](https://www.meetext.xyz/docs/quickstart): Connect a source, approve capabilities, create a customer, send an install link, and watch the deployment validate. - [Sources](https://www.meetext.xyz/docs/sources): MCP, OpenAPI, repository and customer database sources: discovery, approval, access and setup requirements. - [Capabilities](https://www.meetext.xyz/docs/capabilities): Deterministic risk classification, the deliberate second approval for writes, and re-approval when a source changes shape. - [Deployments](https://www.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://www.meetext.xyz/docs/mcp): POST /mcp/products/{slug}, one bearer token per customer environment, three protocol versions, four methods. - [Security model](https://www.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://www.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? Meetext processes the current question to route it and relay the answer. With your own assistant, the bridge sends a stable thread reference rather than conversation history; your assistant manages its memory. This is distinct from saved conversations with the Meetext Agent in the dashboard or customer portal. Capability execution is audited by argument name rather than value, and a call awaiting approval retains its arguments only until the decision. ### 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 AI FDE applies AI to customer-specific deployment and engineering work, with the customer's permissions and acceptance criteria as constraints. Meetext combines a deployment control plane, a permission-aware agent and an engineering loop: it operates installations, identifies unmet requests, drafts changes and verifies outcomes against customer-written cases. Dashboard changes require confirmation, engineering autonomy starts at Observe, and ambiguous scoping or commercial decisions stay with people. It is not a claim that every part of a human FDE's job runs autonomously. ### How is Meetext different from an AI coding agent? A coding agent works on a repository. Meetext also knows which customer asked for a change, their deployed version, approved capabilities, permissions, incident history and agreed acceptance criteria. Its engineering loop uses that context to draft a change and judge whether the customer outcome improved. It complements coding agents rather than replacing general-purpose development tools. ### How does Meetext turn customer requests into verified changes? Meetext observes unmet requests and failing customer cases, groups related gaps across customers, and routes each gap to the person or system that can resolve it. For repository changes it can draft code, validate it, attempt a repair and open a pull request with the customer evidence attached. A gap is not closed just because code was written: the customer's agreed case must pass. ### 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 as an MCP server, an OpenAPI document or a repository, or use a customer's database on eligible plans. Approve the capabilities that customer should receive. Meetext generates the deployment package and security review, then gives you an installation link. The customer completes the destination's authorization or setup steps; Meetext scopes credentials to that customer, validates with a real capability and monitors the installation. Microsoft 365 onboarding is temporarily in Preview. ### Do I have to have an MCP server already? No. Connect an OpenAPI document, discover supported routes from a repository, or use a customer's database on eligible plans. Each source produces capabilities you approve before exposing them. Destination-specific permissions and setup requirements still apply. ### 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. ### What can the Meetext Agent do? Anything the dashboard does, when you ask in plain words: add a customer and hand you their install link, connect a source, approve capabilities, publish a version, share a security review, invite a teammate, email a teammate or a customer's contact, and run checks on a schedule. It works through the same actions as the dashboard's buttons, with the same checks, and every change it proposes waits for you to confirm it. ### Can the AI agent change things without asking? No. A change arrives as a card that says exactly what will happen, and nothing runs until a person presses Confirm. A scheduled check can read and report by itself and email the teammates it was set up to tell; anything else it wants is proposed for a person. It also acts with the permissions of whoever it is working for, never more. ### Can I limit what the agent does for each person on my team? Yes. On the Team page you can turn single permissions on or off for one teammate beyond their role, such as emailing customers or approving capabilities. The agent reads the same permissions as the rest of the product, so whatever is off for a person is off for the agent working on their behalf. ### What does the Meetext Agent cost? It is included on every plan. It runs on the model Meetext hosts and is charged the same way: what the model provider charges, plus a small margin, on what it actually uses. Every answer shows what it cost, and a typical request costs a few cents or less. ### Does Meetext see my customers' data? Capability results are masked under your customer's policy, then 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. A call waiting for a person's approval keeps its arguments only until it is decided. 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 for OAuth destinations. Each vendor registers its own Slack app, Entra application, Connected App or equivalent, and those credentials are stored per deployment target. Google Chat is the deliberate exception: there is no user OAuth consent screen, and the customer installs Meetext's service-account-backed Marketplace app instead. ### Which enterprise systems can Meetext deploy into? Asana, Atlassian, ChatGPT, Claude, Cursor, Google Chat, HubSpot, Linear, Notion, Salesforce, ServiceNow, Slack, VS Code and Zendesk. See the integration directory for each destination's capabilities and setup requirements. ### 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 availability: Claude (available), ChatGPT (available), Asana (available), Atlassian (available), Cursor (available), Google Chat (available), HubSpot (available), Linear (available), Notion (available), Salesforce (available), ServiceNow (available), Slack (available), VS Code (available), Zendesk (available), Microsoft 365 (preview). - Current destination status: 14 destinations are Available. 1 destination is in Preview. - 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. - The vendor assistant bridge forwards a stable thread reference instead of conversation history; the vendor manages its assistant's memory. This is separate from saved Meetext Agent conversations. - 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. - Slack and Google Chat support customer-scoped assistant conversations. Microsoft Teams onboarding is temporarily in Preview. - 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. A call waiting for a person's approval keeps its arguments only until it is decided. - Capabilities that delete data wait for a person's approval on every call, and writes wait when the customer's policy says so, which is the default for new installations. The request is posted in the Slack, Teams or Google Chat thread that asked and on the customer's portal, and an approved call runs exactly once. - Personal data (email addresses, phone numbers, US social security numbers, payment cards that pass the Luhn check, IBANs that pass their checksum, IP addresses) can be masked in every tool result before any client or model reads it, under the customer's policy. Optional tokens let a model act on a masked value without seeing it: the value is resolved only inside Meetext just before the call runs, and tokens are deleted after an hour. - The Meetext Agent does any dashboard step a person asks for in plain words (adding a customer and returning their install link, connecting sources, approving and publishing, sharing security reviews, inviting teammates), through the same actions and checks as the dashboard's buttons. Every change is proposed and runs only when a person confirms it, after which it carries on to the next step. It can email teammates and a customer's registered contact and no other address, runs recurring checks on a schedule as their creator, and acts with each person's own permissions, which can be turned on or off per teammate. Credentials never pass through it, and it never sees the tokens in the links it creates. A customer's agent sees only that customer's installations. - Hosted-model spend is capped per organization and optionally per customer, checked before every model call. Either side can pause a deployment at once; only the side that paused it can resume it. - 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 - 26 September 2026, Ask the agent to do it: Anything the dashboard does, the Meetext Agent can now propose: add a customer and hand you their install link, invite a teammate, publish, share a security review. It can email teammates and customers, run checks on a schedule, and it obeys permissions you now set per person. - 23 September 2026, An agent that asks before it acts: The Meetext Agent answers from your deployment records and proposes changes that run only when a person confirms them. Customers can require approval before anything changes in their workspace, choose what personal data is masked before any AI reads it, and stop everything with one switch. - 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.