Giselle: an Apache-2.0 agent studio built on Next.js and pnpm
Giselle: AI App Builder. Open Source.
At a glance
- What is it?
- Giselle is a TypeScript monorepo that turns agent design into a drag-and-drop canvas, then runs the result against OpenAI, Anthropic or Google AI. It is easy to start and hard to finish, because team collaboration and the template hub are still marked in development.
- Who is it for?
- Adopt Giselle if you want a self-hosted, Apache-2.0 canvas where non-engineers assemble agents and engineers keep the code in one Next.js monorepo. Skip it if you need shared team configuration today, since the README marks Team Collaboration and Template Hub as in development, or if you want a Python-native agent runtime.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 15 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Giselle is aiming at: agents built in a canvas, not a notebook
Most agent tooling assumes you will write the orchestration yourself, in Python or TypeScript, and keep it in a repository only engineers read. Giselle takes the opposite position. The README describes it as "the AI agent studio powering product delivery" and lists a Visual Agent Builder where agents are created and modified through a drag-and-drop interface. The stated audience is a product team, not a research team: the use cases named are a research assistant, a code reviewer, a document generator that produces PRDs and release notes from a codebase, and a workflow automator that chains several models together. Those are delivery tasks. The repository ships under Apache-2.0 and is written in TypeScript, so the artefact you produce is code you can host, diff and deploy rather than a prompt sitting in someone else's dashboard. There is also a hosted option at giselles.ai, which the README says carries the same features as the self-hosted version and includes 30 minutes of free Agent time per month on the free plan. That dual model matters for how you evaluate it: the open repository is the self-host path, and the cloud is the path for people who never want to run pnpm.
How a workflow actually moves: models, knowledge store, GitHub operations
The mechanism the README makes visible is composition across providers. Giselle supports OpenAI, Anthropic and Google AI, and the feature list frames this as agents selecting the best model for each task rather than one model doing everything. That is the central design claim: a step in a workflow is bound to a provider, and the workflow is the unit that mixes them. Around that sit two supporting pieces. The Knowledge Store is described as a place to access and search your code and data, with GitHub vector store integration explicitly supported, which is the retrieval layer that keeps a code-review or document-generation agent grounded in a real repository instead of the model's priors. GitHub AI Operations is the delivery layer, automating issues, pull requests and deployments. Read together, the intended data flow is: a repository is indexed into a vector store, an agent step retrieves from it, a model from one of three providers reasons over the retrieved context, and the output lands back in GitHub as a comment, a PR or a document. The README does not document the internal scheduling, queueing or state model, so how a long-running step survives a restart is not something you can confirm from the material supplied.
Getting it running: four commands and one environment variable
The Quick Start in the README is short enough to quote in full. Clone the repository, cd into it, run pnpm install, create an empty .env.local with touch, append a provider key, then start the dev server with pnpm turbo dev and open http://localhost:3000. The environment variable shown is OPENAI_API_KEY, written into .env.local as a quoted string. The README states that at least one AI provider API key is required and names OpenAI, Anthropic and Google AI as the supported providers, so the exact key names for the other two are not given in the material I have. The turbo prefix tells you the project is a Turborepo workspace, which is consistent with a monorepo that publishes several packages; the README's licence section points to docs/packages-license.md for third-party package licences, which implies a non-trivial dependency tree rather than a single application. For anything beyond local development, the README defers to CONTRIBUTING.md, specifically the section on development environment setup, for self-hosting. There is also a Vibe Coding Guide under docs/vibe/01-introduction.md aimed at people using Claude, Cursor or Windsurf, covering Node.js setup, the project structure and connecting to LLM providers. If you are evaluating Giselle rather than demoing it, that guide is the more useful of the two documents, because it describes the project layout you will have to live inside.
Two of the six headline features are still marked in development
The feature list is honest in a way that should shape your adoption plan. Team Collaboration, described as designing agents collaboratively with shared configurations and contextual awareness, carries an in-development marker. Template Hub, the one-click community template gallery, carries the same marker. So the two features that would make Giselle a team product rather than a single-user tool are the two that are not finished. If your reason for looking at Giselle is that designers and product managers should share agent configurations, the README does not currently support that claim. The roadmap section compounds this: it states that Giselle is in active development and that the public roadmap is still being created. A project without a published roadmap is hard to plan a dependency against, and the release cadence visible in the material does not resolve that on its own. The README also does not describe authentication, multi-tenancy, role separation or how secrets for three providers are stored once you move past a local .env.local file. Those are the questions that decide whether a self-hosted deployment is a weekend or a quarter, and the supplied material does not answer them.
Where Giselle is the wrong tool
Giselle is a poor fit if your agents are already code you are happy with. A repository of Python agent definitions with its own test harness gains nothing from a drag-and-drop canvas, and the TypeScript monorepo becomes a second runtime to keep alive. It is also a poor fit if you need deterministic, auditable execution paths today. The README does not document tracing, replay, or a step-level execution log, and an agent that selects among GPT, Claude and Gemini per task is by construction harder to reproduce than one pinned to a single model at a fixed temperature. If your compliance story requires explaining why a specific output occurred, the multi-model composition feature works against you rather than for you. Finally, treat the in-development markers seriously. Building an internal template library on top of a Template Hub that is still being built means you own the migration when the real one lands. The README gives no compatibility promise for either feature, and no deprecation policy appears in the material.
The alternative worth comparing: LangGraph versus a visual canvas
The obvious comparison is LangGraph, which takes the opposite stance on almost every axis. LangGraph expresses an agent as a graph you define in code, with nodes and edges written explicitly and versioned in your repository; the graph is the source of truth and there is no canvas. Giselle inverts that: the canvas is the authoring surface, and the repository is the runtime that executes what the canvas produced. The practical difference shows up in review. With a code-defined graph, a change to an agent's control flow appears as a diff, and a reviewer can see that a retry edge was added or a branch removed. With a visual builder, the README does not state how the canvas state is serialised, so whether a workflow change produces a readable diff is something you would have to determine from the repository. The trade runs the other way too. A code-defined graph is inaccessible to the product manager who wants to adjust a research assistant's retrieval step, and that is precisely the person Giselle's drag-and-drop interface is designed for. Choose on who needs to edit the agent, not on which framework is more expressive.
Maintenance, licensing and what the Apache-2.0 grant does and does not cover
The repository is licensed under Apache License 2.0, which permits commercial use, modification and redistribution provided you retain the licence and notices. That is a permissive grant, and it is the reason a company can self-host Giselle without a commercial conversation. Two caveats come from the README itself. First, the licence section points to docs/packages-license.md for third-party package licences, which means the dependency tree has its own terms that you should read separately; a permissive top-level licence does not automatically make every transitive package permissive. Second, the hosted service at giselles.ai is a separate product with its own free-tier limit of 30 minutes of Agent time per month, and nothing in the supplied material describes the paid tiers or the terms attached to them. On maintenance cost, the signal in the material is the release history: three patch releases in the v0.75.x line across April 2026, which is a fast-moving version number for a project that has not reached 1.0. Running a pre-1.0 dependency means reading release notes before upgrading, and the README's own note that the roadmap is still being created means you cannot anticipate what is coming. I am not a lawyer and none of this is legal advice; if you are embedding Giselle in a product you ship, have counsel read the LICENSE file and docs/packages-license.md together.
Editorial conclusion
Adopt Giselle if you want a self-hosted, Apache-2.0 canvas where non-engineers assemble agents and engineers keep the code in one Next.js monorepo. Skip it if you need shared team configuration today, since the README marks Team Collaboration and Template Hub as in development, or if you want a Python-native agent runtime. Before committing, verify three things yourself: that pnpm turbo dev boots on your Node version, which provider key you will standardise on among OPENAI_API_KEY, Anthropic and Google AI, and whether the GitHub vector store integration covers the repositories you actually need indexed.
Community notes