alan-sdk-web: a client SDK for Alan AI's hosted voice agent

What the Web SDK actually ships, and what it does not

The repository contains the Alan AI SDK for Web, which the README describes as the piece that lets you "embed Alan's intelligent layer into your Web applications." Everything else in the product, the dialog scripts, the generative model, the validation environment the README calls a "safe and validated environment from your app's APIs, GUIs, and documentation," runs on Alan's servers and is authored in Alan AI Studio. If you clone this repository expecting a conversational runtime, you will not find one. You get a client that connects a browser page to a hosted agent. The README's framing is broader than the code it ships: phrases such as "self-coding engine" and "Application-Level AI" describe the platform, while the repository itself is the embedding layer for one of several supported platforms. The same README lists sibling SDKs for iOS, Android, Flutter, Ionic, Apache Cordova and React Native, which confirms the split. The practical consequence is that your build depends on a third-party endpoint at runtime, and the interesting behaviour is not in your dependency tree.

Who this is for: teams that want a voice agent without building one

The intended user is a front-end or product team that wants a spoken or typed assistant inside an existing web app and does not want to assemble speech recognition, intent handling, retrieval and response generation themselves. The README's pitch is integration speed, claiming companies can add AI-driven interfaces "in days, not months," and the framework list (React, Angular, Vue, Ember, Electron, plus vanilla JavaScript) shows the target is mainstream web stacks rather than a research environment. The dialog scripts are written in JavaScript inside Alan AI Studio, so a JavaScript developer can author them without learning a separate DSL. That is the appeal: one language across the client and the conversation logic. The counter-case is equally clear. If your assistant's answers must be generated by a model you host, or if your data cannot leave your infrastructure, the hosted Studio is the wrong shape regardless of how good the client SDK is.

The data flow: browser to Studio, and back through your app

From the material available, the flow is: the SDK runs in the page, the agent definition lives in Alan AI Studio, and the README says the platform builds its generation context from the app's "APIs, GUIs, and documentation." The README does not document the wire protocol, the authentication mechanism, or how a Studio dialog script calls back into your application code. It points instead to the per-framework client API documentation. That is a real gap for anyone evaluating the SDK from the repository alone, because the most consequential design question, how much of your app the agent can read and act on, is answered in the Studio and client API docs rather than here. The repository's own visible surface is small and mostly organisational: an examples folder, release tags, and links outward. Treat the repository as the distribution channel for the npm package, not as the specification.

Installing it and finding the entry point

The README gives two starting moves. First, sign up for Alan AI Studio at studio.alan.app/register to build and test dialog scripts in JavaScript. Second, embed the agent with the SDK, following the client API page for your framework: alan.app/docs/client-api/web/vanilla, /react, /angular, /vue, /ember, or /electron. The package is published on npm as @alan-ai/alan-sdk-web, and the README's Downloads section links to both the npm page and the GitHub releases page, where the current tag is v.1.8.142 (dated 2026-08-05 in the release list). The README does not print an install command, an import statement, or the name of the SDK key you pass at initialisation. Those details are on the framework-specific documentation pages. The examples folder contains sample apps for React, Angular, Vue, Ember and Electron; the README says each example folder has its own README with launch instructions, and that you then "press the Alan AI button and try interacting with Alan AI." Start there rather than from a blank project, because the examples are the only runnable artefacts described in the material.

The dependency you cannot see from the repository

The clearest limitation is structural. The SDK is a client for a proprietary hosted platform, and the README describes the underlying architecture as "our proprietary Three-Layer AI (3LAI) architecture." Nothing in the repository lets you run that layer yourself. If Alan's service changes its API, its pricing, or its availability, your embedded agent is affected, and your options are limited to what the vendor provides. A second limitation is verifiability. The repository material does not state a licence, and it does not describe the SDK's internal API. For a dependency you ship to end users, that is thin. A third is scope: the README positions the platform for enterprise software, and the surrounding product language (validated environments, app-level AI) suggests procurement and onboarding rather than a drop-in library you evaluate in an afternoon. None of this makes the SDK bad. It makes it a hosted-service client, and it should be evaluated as one, with the same questions you would ask of any vendor SDK: what happens on outage, what the data handling terms are, and how you would remove it later.

Compared with assembling the pieces yourself

The obvious alternative is to build the same capability from separate parts: a browser speech API or a cloud speech-to-text service for input, a language model for generation, and your own code for the intent and action layer. The difference in approach is where control sits. With alan-sdk-web, the dialog scripts live in Alan AI Studio and the generation context is assembled by Alan from your app's APIs, GUIs and documentation, so the platform owns the middle of the pipeline and you own the client integration. With a self-assembled stack, you own the middle too, which means you also own prompt management, retrieval, evaluation and the failure modes that come with them. The trade is time against control. Alan's model buys you a shorter path to a working agent and a single place to edit dialog scripts in JavaScript; the self-assembled model buys you the ability to inspect and replace every stage. Neither is universally correct. If your agent's job is narrow and your data is not sensitive, the hosted route is defensible. If the agent touches regulated data or must keep working when a vendor endpoint does not, the assembled route is the safer bet.

Release cadence, licence and what to check before adopting

The release list shows a steady stream of patch-level tags: v.1.8.140 in early July 2026, v.1.8.141 a few days later, and v.1.8.142 on 2026-08-05. Frequent patch releases on a 1.8.x line suggest active maintenance of the client, though the release notes themselves are not included in the material, so what changed between them is unknown from this repository view. The licence is not stated anywhere in the supplied material, which is the single most important thing to resolve before you ship the package to production. Read the LICENSE file in the repository and the licence field on the npm page for @alan-ai/alan-sdk-web; if neither exists, ask Alan directly at support@alan.app. The README also offers a Slack community for support questions and notes that you can report missing documentation there, which is a reasonable signal that the docs are maintained alongside the SDK. What you cannot determine from this material is the upgrade cost: whether minor versions change the embedding API, whether Studio dialog scripts are versioned with the SDK, or whether a pinned 1.8.x client keeps working against a newer platform. Verify that before pinning a version in package.json.

Editorial conclusion

Adopt alan-sdk-web if you want a voice or chat agent embedded in a React, Angular, Vue, Ember, Electron or plain JavaScript front end and you accept that the dialog logic and the AI runtime live on Alan's hosted platform rather than in this repository. Do not adopt it if you need the full stack to be open source, self-hostable, or readable before you commit. Before writing any integration code, verify the licence terms and the npm package contents directly, because neither is stated in the repository material reviewed here. The README also does not document the SDK's JavaScript API surface, so read the per-framework client API pages for your framework before choosing this over a self-contained library.

Official sources

1. alan-ai/alan-sdk-web on GitHub
2. Issues
3. Project website
4. README
5. Releases