yes! sudocode manages agents at different levels of abstraction. You can steer agents at the `spec` level by building up a spec that contains your intent and requirements, then generate `issues` that capture the implementation details. However you aren't limited to that pattern. You can also just manage agents at the `issue` level to better manage their execution state (think something like a kanban board).
In general, sudocode aims to preserve some of this implementation/planning state (context-as-code) in your codebase so it isn't lost in your chat logs. Keeping this context in your repo makes it accessible to coding agents long after code changes were made, so it functions as a sort of episodic memory for your codebase.
- Simple online verification: the easiest way is to use the public POST /v1/verify endpoint. Any of your services can call this with the agent's credential. It's a stateless check that returns a JSON object confirming if the token is valid and crucially what scopes and user_identifier it was issued for.
- Decentralized/offline verification: for more advanced use cases or high-throughput services that want to avoid a network call you can also verify the credentials offline. The tokens are standard JWTs signed with RS256, and I expose the public keys via a standard /.well-known/jwks.json endpoint on the main domain. You can fetch the keys, cache them and then verify the token signatures locally.
The goal is to make it easy for a developer to get started with the online endpoint, while still providing the standard, scalable method for more mature systems. Thanks for checking it out!
We unified our AI stack into one Postgres instance - and cut our infra and backend code by 90%!
Most teams use 3+ databases already:
- A relational / document store like mongo or postgres,
- A vector DB like Chroma or Pinecone for embeddings,
- Redis for caching, and
- Usually an analytics warehouse, like Athena
You of course have to write and maintain all the glue code & data transformations for each of them. But more importantly, you have to take care of the schema evolution which can be a nightmare when dealing with multiple databases!
Instead we run everything on TigerData (creators of TimescaleDB)’s PostgreSQL platform (TimescaleDB + pgVector + pgAI).
