FelisOrion
Hi everyone,
I recently made Spectre public.
Spectre is an OTP-native Elixir runtime for building AI agents while keeping routing, state, policies and side effects explicit.
I started working on it because I wanted to use agents inside real Elixir applications without moving all the application logic into prompts or hiding it behind a large framework.
The basic idea is simple:
-
the model can help classify requests and propose actions;
-
deterministic application policies decide whether protected actions are allowed;
-
approvals update the agent state but do not automatically execute anything;
-
the host application remains responsible for side effects.
For example, an agent may propose sending a message, changing data or deleting an account. Spectre can represent that action, request confirmation when required and return the result to the application. The application still decides how and when the action is executed.
Spectre uses a small DSL to describe the stable shape of an agent, including routes, policies, actions and interruptions. Normal Elixir modules continue to own the business logic, storage, permissions and integrations.
A small example:
defmodule MyApp.SupportAgent do
use Spectre.Agent
actions MyApp.SupportActions do
protect(:delete_account, with: :delete_account_confirmation)
end
policy :delete_account_confirmation do
request(:confirm_delete_account)
accept(:confirmed_delete, regex: ~r/^yes, delete it$/i)
reject(:cancel_delete, regex: ~r/^(no|cancel)$/i)
attempts(3, then: :cancel_pending)
end
flow :support do
on :PRICING, regex: ~r/\b(price|pricing|cost)\b/i do
reply(:pricing)
end
on :DELETE_ACCOUNT, regex: ~r/\bdelete my account\b/i do
action(:delete_account)
end
end
end
The project is designed around OTP processes and explicit state transitions rather than autonomous execution hidden inside the framework.
I am also developing optional companion libraries for areas such as tool planning, browser interaction, memory and mission planning. They are separate projects because not every agent needs all of these capabilities, and I prefer being able to add only the parts required by an application.
- spectre_kinetic for mapping instructions to validated function-call candidates.
- spectre_lens for browser interaction and agent-readable web pages.
- spectre_mnemonic for working and durable agent memory.
- spectre_directive for missions and plans that can change when new information is discovered.
Spectre is currently in public preview. I am already using it in a few applications, but some APIs may still evolve as I continue testing the design in real projects.
Feedback about the API, architecture and documentation is very welcome.
Source code:
Trending in Announcing
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex











Showing Posts 1 to 2- Show Best Posts
- Show All Posts (oldest first)
- Show All Posts (newest first)
amackera
Nice work! I am watching this space develop into something exciting.
If the app restarts while an agent is waiting for a user to confirm something, does the pending confirmation survive, or does the user have to start over?
FelisOrion
Thanks! The short answer is: it can survive, as long as durable state persistence is configured.
For example, imagine the agent asks, “Do you want me to delete this account?” At that point, Spectre saves both the pending action and the fact that it is waiting for confirmation. If the app restarts, starting the session again with the same
conversation_idrestores that state, so the user can simply reply “yes” or “no” and continue.The agent must use a durable state adapter backed by something like a database:
So the behavior is under the application’s control: use durable state plus the same conversation ID to resume, or use in-memory state when restart recovery isn’t needed.
There are two additional details:
This is a good place for next improvements! Thank you.