# elephant-agent: four slots for a personal model, and a rolling tag for the app > Elephant Agent is a Python agent runtime with a macOS desktop app it calls the recommended surface and a CLI plus dashboard for Linux and cloud boxes. It keeps a four part Personal Model, dispatches Paths to a Herd of subagents, ships no license file, and publishes the macOS build under a tag that never changes. **agentic-in/elephant-agent** — Personal-Model First Self Evolving AI Agent 🐘 - Repository: https://github.com/agentic-in/elephant-agent - Website: https://elephant.agentic-in.ai - Stars: 583 · Forks: 65 - Language: Python - License: not declared - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/agentic-in-elephant-agent ## The macOS app ships from a rolling tag called latest The recommended product surface has no version number to pin. The quickstart sends macOS users to the repository's latest releases page, the only tagged release this project has is literally named latest, and the build configuration defaults both its release tag and its release title to those same words. Meanwhile the Python package declares its version as a 1.0.0.dev0 development marker, and the project classifiers call the status Beta. Four different signals about maturity are in play and none of them increments. That matters because the desktop app is the surface the document recommends first, and it is distributed as a binary that a user cannot rebuild from source without a signing identity they do not hold. The build file does carry an app version variable and a build number variable, so the machinery for real versioning exists; the defaults simply do not use it. Anyone automating a rollout has nothing stable to point at, because the tag moves and two installs a week apart can differ with no way to tell from the channel name. The changelog and the contributing guide sit at the top of the tree and are where to look for what changed, but neither gives you a version to diff against. ## install.sh is piped into bash before you can read it The one line install path is a remote script handed straight to your shell: ```bash curl -fsSL https://elephant.agentic-in.ai/install.sh | bash ``` Nothing in that command shows you what runs. The mitigating detail is that the same script is checked into the repository as a top level file, so you can read it there before deciding, and the tree also carries a contributing guide, an agent guide and a changelog. What the command does not do is pin anything: the URL carries no version segment and no checksum, so the bytes you execute today are not guaranteed to be the bytes you would get next week. The follow-up commands are more concrete, and they are the real interface: ```bash elephant init # choose identity, provider, and curiosity effort elephant status # check provider and local runtime readiness elephant wake # enter the chat TUI elephant dashboard # open Personal Model, questions, evidence, and runtime state ``` For a headless machine there is a documented escape hatch: a dashboard flag that suppresses opening a browser and prints the local URL instead, so you can attach through your own tunnel. That is the shape of the product on a Linux or cloud box. ## The Messaging pane names five channels and the dependencies cover three The desktop app advertises connections to WeChat, Feishu, Discord, DingDing and WeCom. The Python dependency list carries a client for three of them: a Lark SDK for Feishu, a Discord library, and a DingTalk streaming library. Nothing in the tree declares a client for WeChat or WeCom, so two of the five channels named in the interface have no visible transport behind them. Either they are reached through something outside the declared dependencies or the pane is ahead of the code; the tree does not say which. The same list also has one loose bound worth noticing. Every other entry carries an upper limit, from the HTTP client bounded below 4 through the cryptography library, the OpenTelemetry group, the terminal toolkit, the MCP client and the browser automation library, but the DingTalk streaming library is pinned only from below with no ceiling. On a rolling host that is the one package where a new major release can land without your lockfile objecting. The rest of the list is unusually instrumented for an agent. OpenTelemetry appears four times over, including a gRPC exporter, and a tokenizer is a direct dependency rather than something pulled in transitively. Both line up with a usage pane that shows local token flow and runtime events instead of treating cost as a black box. ## One dependency is pinned to an exact version, the rest are ranges Scanning the runtime dependencies, exactly one package is pinned to a single version: the SQLite vector extension at 0.1.9. Every other entry is a range, including the HTTP client, the cryptography library, the OpenTelemetry group, the terminal toolkit, the rich terminal library, the MCP client, the browser automation library and the tokenizer. A single exact pin inside a list of ranges says something about where the authors expect breakage, and here it points at the vector store rather than the network or UI layer. The remainder maps cleanly onto the panes the app exposes. The prompt toolkit plus the terminal UI library account for the chat surface, and the terminal argument parser accounts for the flag vocabulary, including the flag that suppresses opening a browser on a remote box. Playwright accounts for the browser entry in the tools pane, where the document keeps browser, filesystem, MCP and operator actions explicit rather than implicit. A QR code library and a cryptography library are present with no visible caller in the tree summary, so what uses them is inside the application packages. Two absences are worth naming. There is no hosted control plane dependency in the list, so the persistence and coordination layers are local to the machine you install on. And the only repository-wide scanning artefact is a sandbox container file, not a general one, so the container story is about running untrusted work rather than deploying the product. ## The build backend is setuptools while the lockfile belongs to another tool The packaging metadata and the dependency lock come from different ecosystems. The build system section requires setuptools and wheel and names setuptools as the backend, so the wheel is produced by setuptools. At the top of the tree, next to the manifest, the lockfile is the one uv writes, and there is a Python version file beside it. Nothing in the visible metadata reconciles the two, so the pinned resolution and the wheel that gets built are produced by separate tools with separate notions of what a dependency set is. The rest of the manifest is unusually explicit about who runs it. It requires Python 3.12 or newer, and the classifiers name exactly 3.12 and 3.13, so a newer interpreter sits outside the declared support window even though the requirement string would accept it. The author is recorded as a lab rather than a person, and the keywords are the usual agent runtime vocabulary. The package finder shows the project's shape. It includes the application packages for the API, the CLI, the dashboard, the gateway, the learning agents and the reflect module, plus a shared packages directory, and it excludes tests, worktrees and one application package by name. A single console script named after the product is declared, pointing at the launcher module, so every command in the quickstart resolves through one entry point. ## The site package is excluded from the wheel while a hosting config sits beside it Among the excluded application packages is the one that builds the public website. The manifest excludes a site package from the wheel by name, alongside tests and worktrees, so whatever that package produces is deliberately kept out of what gets distributed. At the top of the same tree sits a hosting configuration for a static site builder, and a deploy directory sits beside it. Website source, packaging configuration and deployment configuration therefore live in one repository and are governed by one set of build targets. The build file reflects that split by prefixing its targets. A group covers site install, dev, preview, build, typecheck and content check; a parallel group covers the dashboard; another covers the web client; and a further set covers the macOS build for both target architectures. Shared variables such as the Python interpreter, the changed file list, the base reference and the worktree root sit at the top and are reused across groups, which is how one change can be fanned out to several surfaces. The practical consequence for a reader is that this is not one project with one build. The agent, the dashboard, the marketing site and the desktop app are built by separate target families, and all of them land in the same default branch. The test target names make the same point: alongside the end to end and release suites there are separate targets for a live provider smoke test and a live installed smoke test, which is an admission that the product depends on a provider you supply. ## Signing defaults to no identity and notarization defaults to off The macOS build variables are the ones to read before trusting the recommended download. The signing identity defaults to a dash, which is the convention for an ad hoc, unsigned build, and the notarization variable defaults to empty, so the pipeline does not submit the app for Apple's notarization service unless a caller passes something. Both are overridable on the command line, so a release pipeline that cares can set them; the defaults are what you get when nobody does. The architecture line is set up properly in contrast. Two targets are declared by default, the Apple silicon build and the Intel build, so a single run produces both slices rather than whatever machine you happen to be on. A bundle runtime variable defaults to automatic selection, and a runtime Python version variable pins the interpreter the bundle ships to 3.12, matching the manifest's declared floor rather than the newest release. A signing identity and a notarization flag sit alongside an asset directory variable, which is the shape of a release script that expects to be driven from outside. Put the two halves together: the build is reproducible across architectures and pinned to an interpreter, but out of the box it produces an app that has not been signed or notarized. That is a reasonable default for local builds and a poor one for anything you ask colleagues to install, and closing the gap is a variable on the command line rather than a code change. ## The Personal Model is four fixed slots, not a memory store The document is careful about what the agent is supposed to retain. The model is described as correctable rather than authoritative, and it is divided into four named parts: identity, covering values, boundaries and decision style; world, covering the people, projects, tools and relationships around you; pulse, covering what is alive right now including focus, pressure and energy; and journey, covering lessons, failures, recovery patterns and long running growth. The stated goal is explicitly not to remember everything, but to understand what matters, to show why it matters, and to let you change it. That framing has a consequence for anyone evaluating it. A four part schema is a decision about which categories of information this agent is allowed to hold an opinion about, and anything outside those four has no natural home. The preferences pane is where language, boundaries, model posture and curiosity effort are set, so the boundaries are something you configure rather than something the agent infers about you. The positioning table is equally specific. Existing agent work is sorted into four levels, from executing tasks through carrying context and improving procedures, and the top level is claimed for this project on the grounds that the model grows with the person. The characterisations of the other three levels are attributed to those projects own public positioning, which is worth holding in mind when weighing them against your own needs. ## Conclusion Elephant Agent is a personal agent rather than a task agent, and the design is coherent: a fixed four part model, explicit tool permissions, an inspectable dashboard, and a Herd that keeps judgement with the person. The rough edges are all in the packaging. The install runs a remote script, the macOS app ships from a tag named latest, the build defaults to no signing identity and no notarization, and two of the five messaging channels have no visible client in the dependency list. Before adopting it, read install.sh from the checkout rather than the pipe, decide what the signing variables should be, and confirm which channels you actually need. ## FAQ ### Is Elephant Insurance a real company, and is it this project? No, they are unrelated. agentic-in/elephant-agent is a Python agent runtime with a macOS desktop app and a CLI, authored by Agentic Intelligence Lab, and no license file appears in its top-level tree. ### Does elephant-agent have anything to do with auto insurance quotes? Nothing in this repository sells insurance. The name collision is with a separate insurer; here you install with a shell script and start with a command that chooses identity, provider and curiosity effort. ### Is Elephant Insurance still in business, and does elephant-agent relate to it? No connection. This project publishes macOS builds under a tag named latest, declares its Python version as a 1.0.0.dev0 development marker, and has no insurance product anywhere in its tree. ### Is elephant-agent cheaper than Geico, and how do you compare the two? The comparison does not apply. elephant-agent lets you choose local or hosted models through its providers pane, and shows local token flow in a usage pane. You supply the provider and pay that provider directly. ## Sources - [agentic-in/elephant-agent on GitHub](https://github.com/agentic-in/elephant-agent) - [Issues](https://github.com/agentic-in/elephant-agent/issues) - [Project website](https://elephant.agentic-in.ai) - [README](https://github.com/agentic-in/elephant-agent/blob/main/README.md) - [Releases](https://github.com/agentic-in/elephant-agent/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/agentic-in-elephant-agent