Live data from Hacker News

Show HN: Pixelagent – Build your Stateful Agent Framework in 200 lines of code

github.com

1–10 of 16 posts

Re: Show HN: Pixelagent – Build your Stateful Agent Framework in 200 lines of code

#4
Exciting to see a fellow builder in the space! Love how memory management and observability is built-in.

Today, I just re-implemented Google's AlphaEvolve for Perlin noises using my own minimal agentic framework (https://toolkami.com/alphaevolve-toolkami-style/), will probably steal a trick or two from you.

Re: Show HN: Pixelagent – Build your Stateful Agent Framework in 200 lines of code

#6
Your readme doesn't mention any example of multiple agents. We don't need another wrapper to anthropic/openai/*. Without being able to select between multiple tools/agents - you only need 2 lines of code to achieve llm calls, and another 2 lines for state management.

That said the interface is more idiomatic that others agent frameworks that show up here.

It also wasn't clear where the last N messages is being persisted. Db/file/adapters/?

Good luck!

Re: Show HN: Pixelagent – Build your Stateful Agent Framework in 200 lines of code

#9
I don't know why Pierre's post is dead, but I wanted to ask if it is accurate to describe Pixelagent as an MCP-compatible memory layer, and what its competitors are.

If memory is the centerpiece, I suggest leading with it, rather than the ambiguous "Your AI Data Infrastructure".

Re: Show HN: Pixelagent – Build your Stateful Agent Framework in 200 lines of code

#10
post #9

I don't know why Pierre's post is dead, but I wanted to ask if it is accurate to describe Pixelagent as an MCP-compatible memory layer, and what its competitors are. If memory is the centerpiece, I suggest leading with it, rather than the ambiguous "Your AI Data Infrastructure".

You can indeed turn anything that you want into an MCP server, e.g. https://github.com/pixeltable/pixeltable-mcp-server.

Pixelagent is a reference implementation for a multimodal agent framework to show that an agent class is easy to build and users should be empowered to build their own from scratch for their use cases.

Regarding Memory, to me it's just about Data Storage, Indexing, Orchestration, and Retrieval and I don't know why we should abstract Memory away from users. Memory will mean so many different things for many use cases.

Let's say you want:

- Working memory: Holds current context and immediate interaction history within the agent's context window -> this is just about passing Q&A pairs to maintain context alongside with roles.

- Episodic memory: Stores specific past experiences and interactions -> this is just about indexing past exchanges and having semantic search on it.

- Semantic memory: Organizes specific knowledge in structured formats -> this is just about building a custom logic (udf) to decide how and what to extract insight from and then retrieve it.

I've implemented them all in this example: https://github.com/pixeltable/pixelbot

Post reply on HN