Forward deployed engineering, answered plainly.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.