# Meetext, in full > 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. ## AI in customer workspaces 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. Page: https://www.meetext.xyz/ai-in-customer-workspaces ## Pricing Every Meetext plan is free during launch. Compare customer and environment limits, with published monthly and annual rates for when billing begins. Page: https://www.meetext.xyz/pricing ## How support status is decided Meetext publishes customer-facing availability from the same catalog used by the deployment service. Current status: 14 destinations are Available. 1 destination is in Preview. Each destination page explains installation, approval, identity, permissions, credentials, versioning, failure handling and monitoring. Microsoft 365 and Teams are temporarily in Preview; available destinations can be configured for customer deployments today. ## Destinations Where a vendor's product is installed. Each entry states its real status, then answers the same eleven questions, so two destinations can be compared on the same terms. ### Claude Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. Every other destination is somewhere Meetext installs into. Claude is the opposite: it connects inward, over the public internet, to an endpoint that already exists. What makes it a deployment is not the protocol but everything around it. **How installation normally works.** No install and no redirect. The customer receives a server URL and a token on their installation page and adds a custom connector in Claude. **Who has to approve it.** A workspace owner or administrator, since a connector is available to the people they choose. **Identity and OAuth model.** A token Meetext issues for this environment alone. There is no third-party grant, because there is no third party. **What Meetext owns.** The hosted MCP endpoint, the per-customer token, the frozen package that decides which capabilities that token can reach, and revocation. **What the customer owns.** Their Claude workspace, and who inside it can use the connector. **Capability and permission model.** Not provider scopes. The token reaches exactly the capabilities this customer is entitled to at the version approved for them, and nothing else the vendor has published. **Validation.** The connector proves itself by connecting. A request arriving with this environment's token is the only evidence anybody finished the setup, so nothing is marked connected before it happens. **Credential lifecycle.** One token per environment, rotatable. Rotating it disconnects this customer's connector and no other. **Deployment versioning.** Nike stays on the package approved for Nike when the vendor publishes a new version. A hosting platform has one server at one version; this is one customer's installation of it. **Typical failure modes.** An endpoint that is not publicly reachable, which fails silently: the customer pastes it, Claude reports a connection error, and nothing on this side hears about it. Refused at publish rather than discovered later. **Operational monitoring.** Whether the token is issued and the endpoint is a public address Claude could reach, plus whether it has ever actually connected. Page: https://www.meetext.xyz/integrations/claude ### ChatGPT Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. The same shape as Claude, and deliberately a separate destination: a vendor can sell one without the other, and revoking one must not touch the other. **How installation normally works.** No install and no redirect. The customer receives a server URL and a token and creates a connector in ChatGPT settings. **Who has to approve it.** A workspace owner, on a Business, Enterprise or Edu plan. Connectors are not a personal-account feature. **Identity and OAuth model.** A token Meetext issues for this environment alone, separate from the same customer's Claude connector. **What Meetext owns.** The hosted MCP endpoint, the per-customer token, the frozen package behind it, and revocation. **What the customer owns.** Their ChatGPT workspace, and who inside it can use the connector. **Capability and permission model.** Not provider scopes. The token reaches this customer's entitlement at their approved version. **Validation.** Proven by connecting, not by being configured. Nothing is marked connected until a request arrives. **Credential lifecycle.** One token per environment, rotatable, and independent of every other destination this customer runs. **Deployment versioning.** Per customer, not per server. A new vendor version does not move an installed customer. **Typical failure modes.** A non-public endpoint, refused at publish. Beyond that, a workspace on a plan without connector support, which is the customer's to resolve. **Operational monitoring.** Token issued, endpoint publicly reachable, and whether the client has ever connected. Page: https://www.meetext.xyz/integrations/chatgpt ### Asana Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. Asana is the strictest test of credential handling here. Access tokens last an hour and the refresh token rotates, so a single dropped replacement loses the customer's grant a day later, looking like something they did. **How installation normally works.** An OAuth redirect. The account that authorizes is the account the deployment acts as, and the workspace it belongs to is read and recorded during the callback. **Who has to approve it.** Any Asana user who is a member of the workspace this is for. **Identity and OAuth model.** OAuth 2.0 for one user, scoped in practice by the workspace recorded at installation. A token reaches every workspace that person belongs to, including personal ones, which is why the workspace is pinned rather than inferred per call. **What Meetext owns.** The OAuth flow, storing each rotated refresh token, refusing an exchange that returns no replacement, the recorded workspace, and revocation. **What the customer owns.** Their Asana workspace and the account that authorized it. **Capability and permission model.** Granular scopes are opt-in per application. Meetext always asks for the narrow set, so an app without them grants more than was requested rather than less, and that difference is visible in the granted scopes rather than hidden. **Validation.** A real read of the recorded workspace's projects, plus a check that a refresh token was actually stored, because without one the install stops working within the hour. **Credential lifecycle.** Rotating. The replacement is stored on every exchange and an exchange without one is refused at the moment it happens rather than discovered as a dead grant the next morning. **Deployment versioning.** Per customer. Publishing does not move an installed workspace. **Typical failure modes.** A first exchange that returns no refresh token, which is refused rather than recorded as an installation that expires in an hour. **Operational monitoring.** Token validity and whether the rotating refresh token is still stored, which is the thing that breaks quietly here. Page: https://www.meetext.xyz/integrations/asana ### Atlassian Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. Atlassian is two deployment stories wearing one brand. Cloud apps go through Forge or Connect and the Marketplace; Data Center apps are installed by an administrator into infrastructure the customer runs. A page that says "we integrate with Jira" has not said anything. **How installation normally works.** Cloud: a Forge or Connect app, installed by a site administrator, usually via the Marketplace. Data Center: a plugin installed into the customer's own instance, on their upgrade schedule. **Who has to approve it.** A Jira or Confluence site administrator. In Data Center, whoever owns the servers, which is frequently a different team with a different change process. **Identity and OAuth model.** OAuth 2.0 (3LO) for cloud, with app-scoped tokens for Forge. Data Center authentication is whatever the customer's instance is configured for, which may be SAML, may be LDAP, and is not something the vendor controls. **What Meetext owns.** The Cloud OAuth 3LO flow, resolving the cloud id that every API call needs and which is only discoverable after authorization, and validation that reads a real project. Data Center is declared and refused at deploy time rather than treated as Cloud, because a wrong assumption there fails inside your customer's own datacentre. **What the customer owns.** The site or the instance, project permissions, and the Marketplace approval if their policy requires one. **Capability and permission model.** Scopes for cloud, plus per-project permission schemes that can make a granted scope useless on the project that matters. **Validation.** Reading a project the customer actually uses, not the sample project, because permission schemes differ per project. **Credential lifecycle.** Rotating OAuth tokens on cloud. Data Center credentials live in the customer's instance. **Deployment versioning.** Marketplace app versions and per-site installed versions are separate, and Data Center customers upgrade on their own schedule, sometimes years apart. **Typical failure modes.** A scope granted at site level and a project permission scheme that denies it anyway. Cloud and Data Center behaviour differing under identical configuration. Rate limits on large instances. **Operational monitoring.** Health asks Atlassian which sites the rotating token can still reach and verifies that the installed cloud id remains present. Installation validation separately reads a real Jira project, because a site-level scope can coexist with a project permission scheme that denies every useful project. Page: https://www.meetext.xyz/integrations/atlassian ### Cursor Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. The same inward shape as Claude, aimed at a different room. Where a customer's engineers already work inside an editor, the vendor's product reaches them there rather than asking them to leave it. **How installation normally works.** No install and no redirect. The customer receives a server URL and a token and adds an MCP server under Settings, Tools and Integrations. **Who has to approve it.** Whoever administers the team's Cursor configuration. In a company this is usually set once centrally rather than by each developer. **Identity and OAuth model.** A token Meetext issues for this environment alone, separate from the same customer's other connectors. **What Meetext owns.** The hosted MCP endpoint, the per-customer token, the frozen package behind it, and revocation. **What the customer owns.** Their Cursor configuration, and which of their developers it reaches. **Capability and permission model.** Not provider scopes. The token reaches this customer's entitlement at their approved version, and nothing else the vendor has published. **Validation.** The connector proves itself by connecting. Nothing is marked connected until a request arrives carrying this environment's token. **Credential lifecycle.** One token per environment, rotatable, independent of every other destination this customer runs. **Deployment versioning.** A new vendor version does not move an installed customer. Their editor keeps calling the package approved for them. **Typical failure modes.** An endpoint that is not publicly reachable, which fails silently on the customer's side. Refused at publish rather than discovered later. **Operational monitoring.** Token issued, endpoint publicly reachable, and whether the client has ever connected. Page: https://www.meetext.xyz/integrations/cursor ### Google Chat Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. Google Workspace™ is not one destination. Google Chat™ apps, Google Docs™ and Gmail™ add-ons, Google Drive™ integrations and Gemini™ extensions have different manifests, different reviews and different failure modes. An adapter that treats "Google" as one thing cannot tell you what it actually installed. **How installation normally works.** Meetext configures and publishes one Chat app through Google Workspace™ Marketplace. The customer installs that app for their domain or personal account, then presents a single-use code in the Chat space that should belong to this environment. **Who has to approve it.** A Workspace super admin for domain-wide installation, or an individual user for a personal install. Meetext records which kind occurred so a personal test is never presented as a domain-wide rollout. **Identity and OAuth model.** The app authenticates as itself with Meetext's service account and the chat.bot scope. There is no user OAuth grant, refresh token or consent screen. Domain-wide delegation is deliberately not used because answering as the app does not require impersonating anybody in the customer's domain. **What Meetext owns.** The Marketplace app, service-account credential, signed-event verification, and the single-use code that binds one Chat space to exactly one customer environment. Events resolve by space, so two personal installs under gmail.com cannot cross customer boundaries. **What the customer owns.** Installation and removal of the app, plus the Admin console policies that decide who can use it. Removing one customer installation does not revoke Meetext's shared app credential or interrupt another customer. **Capability and permission model.** Exactly chat.bot, held by the app rather than granted by a customer. User scopes such as chat.messages and chat.spaces are not requested. Add-on, Drive and Gemini surfaces are refused at deploy time instead of silently widening access. **Validation.** Google's signature and project audience are verified before an event can claim anything. The app token, installed space, capability listing and a real execution are then checked, and the one-time code cannot be replayed. **Credential lifecycle.** Meetext mints short-lived app tokens from one service-account key. There is no customer refresh token to expire or reconnect. Rotating that key is a platform operation because it affects every Google Chat™ installation. **Deployment versioning.** The capability package is frozen per customer, as everywhere. The shared Marketplace listing and Chat app configuration are a separate platform-wide version that Meetext operates for every customer. **Typical failure modes.** The Marketplace listing is not visible to the customer's domain. Google cannot reach the webhook. The service-account key was rotated without updating Meetext, or the inbound event has the wrong project audience. Non-Chat surfaces are refused before installation. **Operational monitoring.** Outbound health proves the app token can still read the installed space. Inbound events record the public address Google actually reached, so a stale Cloud console webhook after a cutover is reported instead of being hidden by a healthy outbound probe. Page: https://www.meetext.xyz/integrations/google-workspace ### HubSpot Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. HubSpot is comparatively simple, which makes it a good early test of whether the destination model generalises without special cases. **How installation normally works.** A public app installed into the customer's portal through an OAuth install link, or a private app for a single portal. **Who has to approve it.** A HubSpot super admin, or a user with app installation permission. **Identity and OAuth model.** OAuth 2.0 per portal, with refresh tokens and portal-scoped access. **What Meetext owns.** The public app OAuth flow, resolving the portal id by introspecting the token because it is not in the token response, reading the scopes the install actually holds rather than the ones we asked for, and per-portal credential storage. **What the customer owns.** The portal, and which objects the app may touch. **Capability and permission model.** Granular scopes per object type. Adding a scope to a published app requires existing customers to reinstall, which is a per-customer deployment event rather than a release. **Validation.** Reading a real object in the portal after install. **Credential lifecycle.** Refresh tokens per portal, rotated before expiry. **Deployment versioning.** App versions are global; installed scopes are per portal. Those diverge the moment you add a scope. **Typical failure modes.** Scope changes requiring reinstall across the whole customer base. Portal-level API limits shared with everything else the customer runs. **Operational monitoring.** Health compares the scopes this installation holds against what the current package needs. HubSpot does not extend existing installs when an app adds a scope, so an older customer shows as needing a reinstall instead of the capability silently failing for them. Page: https://www.meetext.xyz/integrations/hubspot ### Linear Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. Linear is where a customer's product and engineering work actually lives, and it is the cleanest test of a destination whose permission model is coarser than Meetext's: two scopes for a whole workspace. **How installation normally works.** An OAuth redirect. The customer chooses the workspace and approves, and the authorization carries actor=app so anything created afterwards is attributed to the vendor's application rather than to the admin who clicked Approve. **Who has to approve it.** Any member who can authorize applications for the workspace. **Identity and OAuth model.** OAuth 2.0 per workspace. The workspace is read from the API during the callback, because it is not in the token response. **What Meetext owns.** The OAuth flow, resolving which workspace a grant belongs to, per-workspace credential storage, renewal where the application issues refresh tokens, and revocation. **What the customer owns.** Their Linear workspace, and whether applications may read it at all. **Capability and permission model.** Linear grants read and write, and nothing finer. Least privilege here is a decision about whether to ask for write at all, so a read-only product never does. Destructive capabilities raise the risk on the same grant rather than inventing a scope Linear does not have. **Validation.** A real GraphQL query: the viewer plus one page of issues. A workspace with no issues passes; a grant that cannot see issues at all does not, and that is the state a restricted workspace produces. **Credential lifecycle.** Refresh tokens are opt-in per application. A workspace connected through an application without them is told to reconnect for that stated reason rather than because renewal quietly failed. **Deployment versioning.** The frozen package decides which capabilities this workspace reaches, independently of what the vendor has since published. **Typical failure modes.** A refusal arrives as HTTP 200 with an errors array, so a transport-level check alone would read a rejected query as healthy. The adapter reads the body. **Operational monitoring.** Token validity, and whether the grant still holds the scopes the current package needs. Page: https://www.meetext.xyz/integrations/linear ### Notion Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. Notion is the destination that breaks the scope model, which is exactly why it is worth having: it proves the deployment unit survives a provider whose permission system is a page picker rather than a scope list. **How installation normally works.** An OAuth redirect that ends in Notion's own page picker. The customer selects which pages and databases the integration may reach. **Who has to approve it.** Any workspace member who can add integrations, though what they can share is limited to what they can see. **Identity and OAuth model.** A bearer token for the workspace, issued against HTTP Basic credentials because Notion refuses them in the request body. **What Meetext owns.** The OAuth exchange, the workspace and bot identity recorded from the token response, per-workspace credential storage, and revocation. **What the customer owns.** Their workspace, and the selection itself. Sharing can be withdrawn inside Notion at any time without touching the grant. **Capability and permission model.** There are none in the OAuth sense. What is shown is what the integration will be able to do with whatever the customer picks, in Notion's own words, so the page and the consent screen say the same thing. **Validation.** A real search. An integration can authorize perfectly and have nothing shared with it, which reads as green everywhere else and returns nothing to every capability. That is reported as a failure with the fix. **Credential lifecycle.** The token does not expire and cannot be refreshed. Stated as an answer rather than left as a missing renewal path. **Deployment versioning.** Per customer. The API version is pinned by Meetext so an account created next year behaves like one created last year. **Typical failure modes.** The quiet one: somebody removes the integration from the pages it was connected to. No OAuth event fires, the token stays valid, and everything returns nothing. Health checks for it. **Operational monitoring.** Token validity, and whether the integration still reaches any shared content at all. Page: https://www.meetext.xyz/integrations/notion ### Salesforce Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. Meetext connects each customer's Salesforce org through Connected App OAuth, keeps its instance URL and credentials scoped to that environment, and validates the deployment with a real capability. The customer's object permissions, field-level security and change process remain in force, with sandbox and production addressing handled explicitly. **How installation normally works.** A managed or unmanaged package, or a Connected App, installed into a sandbox first and then promoted to production through the customer's own change process. There is no version of this that takes an afternoon. **Who has to approve it.** A Salesforce administrator, and usually a change advisory board as well. In regulated industries the sandbox-to-production promotion is a scheduled event, not a request. **Identity and OAuth model.** OAuth 2.0 against the customer's org, with the JWT bearer flow for server-to-server. Connected App policies, IP restrictions and permitted-users settings all decide whether a grant works, and all of them are the customer's. **What Meetext owns.** The Connected App OAuth flow, with sandbox and production as separate environments, recording the org's instance url because every call must go there, per-environment credential storage, and validation that runs a real query and checks the fields came back. Field level security hides data by omitting it rather than failing, so a check that only counted rows would call a broken deployment healthy. **What the customer owns.** The org. Its objects, its sharing rules, its profiles, its change process, and the decision about what a package is allowed to read. **Capability and permission model.** Object and field level security, permission sets, sharing rules. A capability that reads an Opportunity is not one permission, it is a profile, a permission set and a sharing model that has to agree. **Validation.** Executing against a sandbox, then against production, and treating those as different environments rather than the same one twice. **Credential lifecycle.** Refresh tokens with org-level revocation. Connected App policy changes can invalidate a grant without anything failing until the next call. **Deployment versioning.** Package versions and org state are separate axes, and an upgrade can succeed while leaving the org in a configuration the new version does not expect. This is precisely the problem the deployment control plane exists to model. **Typical failure modes.** Field level security silently returning nothing rather than an error. Governor limits under load. A sandbox refresh wiping configuration. A validation rule written in 2019 rejecting a record the integration creates. **Operational monitoring.** The three layers, with the org's daily API allowance watched. That allowance is shared with everything else the customer runs, so exhausting it degrades Salesforce as a named dependency rather than reporting your product as broken. Page: https://www.meetext.xyz/integrations/salesforce ### ServiceNow Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. ServiceNow implementations are mostly repeated configuration, rebuilt by hand per instance, promoted through update sets that drift from each other. It is the clearest example of work that looks bespoke and is not. **How installation normally works.** A scoped application or an integration built directly in the instance, developed in a sub-production instance and promoted through update sets. Nothing about this is a single install step. **Who has to approve it.** The ServiceNow platform team, and a change request through the customer's own ITSM process. Which is, with some irony, managed in ServiceNow. **Identity and OAuth model.** OAuth 2.0 against the instance, or basic auth against an integration user, which is still common and still what security review objects to. **What Meetext owns.** The instance OAuth flow, write-only customer app-secret storage, per-environment tokens, and validation that reads a real record and checks a named field survived the ACLs. ServiceNow cannot tell us which instance a grant belongs to, so the instance and its OAuth app are configured before installation rather than guessed after somebody approves something. **What the customer owns.** The instance, an OAuth API endpoint registered inside it, its update set process, its change windows, and every piece of configuration somebody added in 2018. **Capability and permission model.** Roles and ACLs. A capability needs a role that needs an ACL that may or may not exist in this instance. **Validation.** Health checks against the instance, and execution in a sub-production instance before production is touched. **Credential lifecycle.** Instance-scoped OAuth tokens, or an integration user whose password is in somebody's vault. **Deployment versioning.** Update sets are already a version mechanism and they drift. A per-customer deployment record that knows which update set is actually applied is the missing half. **Typical failure modes.** Update set collisions. Configuration present in the sub-production instance and absent in production. Platform upgrades changing behaviour under a working integration. **Operational monitoring.** Health reads the configured instance with the stored token and separates a revoked session from an unreachable ServiceNow dependency. Installation validation also reads a named field, because an ACL can return a row while hiding the data the capability needs. Page: https://www.meetext.xyz/integrations/servicenow ### Slack Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. Slack is the easiest destination to install into and the easiest to get quietly wrong. A workspace admin can approve in a minute, which means nobody builds a process, which means nobody notices that the token belongs to a person who has since left. **How installation normally works.** Someone at the vendor creates a Slack app, works out which scopes the capabilities need, sends the customer an OAuth link, and waits. If the workspace restricts app installation, the link goes to an admin queue and nothing happens until somebody clears it. **Who has to approve it.** A workspace owner or admin, or any member if the workspace has not restricted app installs. Large enterprises almost always have restricted it, and the request lands in an approval queue that nobody is paged about. **Identity and OAuth model.** Slack OAuth v2. The grant produces a bot token scoped to one workspace, and optionally a user token acting as the installing person. Meetext stores the grant under a name scoped to a single customer environment, so no credential is ever shared between two customers. **What Meetext owns.** Generating the app manifest from your capabilities, running the OAuth exchange, storing the grant per environment, translating capabilities into slash commands within Slack's length limits, executing a real read capability to prove the install works, and watching for the revocation errors that mean the grant is gone rather than merely failing. **What the customer owns.** The decision. The consent screen names your application, lists the scopes, and says why each one is needed. Uninstalling is theirs and it takes effect at Slack, not just in Meetext's copy of it. **Capability and permission model.** Capabilities become slash commands, so a capability whose name exceeds Slack's command length limit is refused at deploy time rather than discovered missing. Read, write and destructive capabilities carry their risk into the deployment package, and destructive ones need approval before they can be published at all. **Validation.** Authentication is checked against Slack, the destination API is reached, the granted scopes are compared with the ones the package requires, capabilities are listed back through the MCP endpoint, and one real read capability is executed. A token that exists is not evidence. **Credential lifecycle.** Slack bot tokens do not expire by default, which is the problem: nothing forces the vendor to think about them until the installing user is deprovisioned and the grant silently dies. Meetext records the grant with its scopes and version, and treats Slack's revocation errors as a disconnection rather than a failure, because only the customer can fix it. **Deployment versioning.** The deployment package is frozen at install. Publishing a new product version does not move this customer until somebody moves them, so a capability you removed on Tuesday is still there for a customer who has not upgraded. **Typical failure modes.** The workspace restricts installs and the request sits in a queue. A scope was added to the product after this customer installed, so their grant no longer covers the package. The installing user leaves the company. Slack rate limits during a burst and every capability fails at once, which is not your product being broken. **Operational monitoring.** Health runs on an interval and separates the three layers: whether the MCP endpoint answers, whether the Slack grant still works, and whether capabilities actually execute. Those disagree often, and a summary that averages them describes none of the three. Page: https://www.meetext.xyz/integrations/slack ### VS Code Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. Deliberately separate from Cursor rather than one 'editor' destination: a customer standardised on one is not a customer standardised on the other, and an environment is what gets sold, revoked and reported on. **How installation normally works.** No install and no redirect. The customer receives a server URL and a token, and adds an HTTP MCP server. In an organisation this normally lives in workspace settings rather than on each machine. **Who has to approve it.** Whoever owns the repository or workspace settings the configuration lands in. **Identity and OAuth model.** A token Meetext issues for this environment alone. **What Meetext owns.** The hosted MCP endpoint, the per-customer token, the frozen package behind it, and revocation. **What the customer owns.** Their workspace configuration, and which of their developers it reaches. **Capability and permission model.** Not provider scopes. This customer's entitlement at their approved version. **Validation.** Proven by connecting, not by being configured. **Credential lifecycle.** One token per environment, rotatable, and revocable alone. **Deployment versioning.** Per customer, not per server. Publishing does not move an installed customer. **Typical failure modes.** A non-public endpoint, refused at publish. Beyond that, a configuration committed to a repository where the token should not be, which is why the token is per environment and rotatable. **Operational monitoring.** Token issued, endpoint publicly reachable, and whether the client has ever connected. Page: https://www.meetext.xyz/integrations/vs-code ### Zendesk Status: available. Available for customer deployments, with customer-scoped authorization, validation and lifecycle management. The second destination whose address is per customer rather than per product. ServiceNow proved the shape; Zendesk shows it was a shape and not a special case. **How installation normally works.** An OAuth redirect to the customer's own host. The subdomain has to be known before the flow starts, so a wrong one fails before authorization rather than authorizing into another company's helpdesk. **Who has to approve it.** A Zendesk administrator. An agent without admin rights can complete the same screen and produce a grant that cannot see other agents' tickets, so the instructions say so. **Identity and OAuth model.** OAuth 2.0 per account, with the authorizing user's email and role recorded so it is visible who the deployment acts as. **What Meetext owns.** The per-subdomain OAuth flow, proving which account actually authorized rather than trusting the subdomain somebody typed, credential storage, renewal where the client issues refresh tokens, and revocation. **What the customer owns.** Their Zendesk account, and which agent authorized it. **Capability and permission model.** Read is account-wide because Zendesk has no per-object read scope. Writes are per object type, so a deployment that only touches tickets never asks for users. **Validation.** A real read of the ticket list against the customer's own host. **Credential lifecycle.** Tokens do not expire unless the client opted into rotation. Renewal is attempted where a refresh token exists and the customer is told to reconnect, with the reason, where it does not. **Deployment versioning.** The subdomain is re-read live so a corrected value reaches deployments that already exist. The object list is not: it decides the scopes the customer approved, and moving those under an installed customer would make the freeze a decoration. **Typical failure modes.** A grant made by a non-admin agent, which authorizes and then cannot see most of the helpdesk. **Operational monitoring.** Token validity against the customer's host, and scope drift against the current package. Page: https://www.meetext.xyz/integrations/zendesk ### Microsoft 365 Status: preview. Microsoft 365 and Teams support is temporarily in Preview while live tenant onboarding is completed. Limit: Microsoft 365 and Teams onboarding is temporarily unavailable while Meetext completes tenant provisioning. Microsoft is where the difference between user consent and admin consent stops being a detail. AADSTS90094 and AADSTS90093 mean different things, and only one of them is something the person in front of you can fix. Getting that wrong turns a two-hour install into a three-week escalation. **How installation normally works.** The vendor registers an application in Entra, decides which Graph permissions the capabilities need, and sends a consent link. Whether that link works depends on the tenant's consent policy, which the vendor cannot see and the customer often cannot describe. **Who has to approve it.** A Global Administrator or Privileged Role Administrator when admin consent is required, which it is for any Graph permission on the admin-only list. Otherwise the installing user can consent for themselves, and the deployment works for exactly one person. **Identity and OAuth model.** Tenant-scoped OAuth against login.microsoftonline.com, tokens against Microsoft Graph. The tenant is recorded as a vendor-scoped pseudonym rather than as raw tenant data, so the same customer is recognisable across destinations without Meetext holding a globally stable identifier. **What Meetext owns.** Distinguishing admin consent from user consent before the customer hits it, naming the required Graph permissions and which of them an administrator must approve, running the tenant-scoped exchange, refreshing tokens before they expire, and normalising AADSTS codes into signals that mean something. **What the customer owns.** Consent, and the tenant policy that decides who can give it. Conditional Access is theirs too, and when it blocks token issuance Meetext reports that rather than guessing which policy did it. **Capability and permission model.** Graph permission names map to capability requirements. Permissions only an administrator can consent to are marked as such in the deployment package, so the security review shows them before the install rather than after it fails. **Validation.** Authentication against Graph, scope comparison against the package, capability listing, and a real execution. Admin consent required is reported as waiting on the customer's administrator, which is a state, not a failure. **Credential lifecycle.** Refresh tokens are exchanged before expiry rather than on failure. A removed scope produces a re-authorization request rather than a quiet degradation, and a revoked grant disconnects the environment and offers a reconnection link. **Deployment versioning.** Same freeze as everywhere. A new product version that needs a new Graph permission cannot silently apply to an existing customer, because the consent they gave was for a package with a different digest. **Typical failure modes.** AADSTS90094: admin consent required, which may be the tenant restricting user consent or may be a permission that always needs an admin. AADSTS90093: user consent blocked by policy. AADSTS65001: consent never granted. AADSTS53003: Conditional Access blocked issuance, and the error does not say which policy. **Operational monitoring.** Graph is watched as a named dependency. When Graph is degraded the deployment is degraded because of Microsoft, and the incident says so, so nobody spends a day debugging their own code during somebody else's outage. Page: https://www.meetext.xyz/integrations/microsoft-365 ## Sources Four source types produce approved capabilities for customer deployments. - 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. ## Technical facts - Public API: 202 operations, OpenAPI document at /openapi.json. - MCP protocol versions supported: 2025-06-18, 2025-03-26, 2024-11-05. Transport is Streamable HTTP. - Deployment states: 9, with legal transitions between them. - Health layers, reported separately because they disagree: capability, deployment, protocol. - A failing capability returns a result with isError set, never a JSON-RPC error. The distinction decides whether a model retries. - 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 a secret manager under a name scoped to a single customer environment, never in the database and never shared between customers. - Write and delete capabilities require a deliberate second approval, revoked if the source later changes that operation's shape. - The deployment package is frozen per customer. Publishing a new product version does not move an existing customer until somebody moves them. - Rollback targets are earlier deployments of that environment which actually reached a working state, and the rollback revalidates rather than assuming the old package still works. - Operational history is append-only and replayable. A deployment context document can be generated for any environment, carrying provenance on every inference and no secrets. ## Questions and answers Each answer 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. ## 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. ## 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. - 20 August 2026, Seven destinations, and a rule about what counts as shipped: Salesforce, ServiceNow, Atlassian and HubSpot joined the deployment catalog with destination-specific authorization and lifecycle handling. - 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. - 28 July 2026, Shareable security review: The artifact an enterprise security team reads before approving an installation, with every claim carrying where it came from. - 2 July 2026, Deployment timeline and attribution: Every second of a deployment's elapsed time traced to an interval, the records that created it, and the rule that attributed it. - 10 June 2026, Three health layers: Protocol, deployment and capability health separated, because they disagree and the disagreement is the useful part.