Every problem has an AI tool. We test, you grow safely.

“Memory” isn’t one single thing, and that’s where people get lost. There’s session memory (the context window, which sooner or later runs out), persistent memory (the facts that carry over from one session to the next) and retrieval of broad knowledge (RAG on a vector store). In practice a mix works: file-based memory for the stable facts the agent must always have to hand, a vector store for knowledge too big for the context, and dedicated MCPs that expose all this to the agents cleanly. It’s the pattern we use on our own systems: agents “remember” because memory lives outside the model, not inside it. We show you what holds up and what to avoid, so you don’t build a memory that gets corrupted the first time it grows.

The honest answer is “both”. For common tasks, ready-made plugins and skills get you started in hours and there’s no point reinventing them. But on the processes that make you different — the ones specific to your business — ready-made tools become generic and the real value lies in custom work. We develop vertical skills and plugins for our own daily use: we give you the right ready-made ones where they’re enough and custom ones where they’re needed, without making you choose blindly or pay for development where a solid solution already exists.

Almost never from scratch. On GitHub there are mature repositories that cover 80% of what you need, and starting from there saves you months. The point is that “lots of stars” doesn’t mean “works in production”: many agents shine in the demo and fall apart on real cases. The work that matters is selection (which repository holds up), securing (closing the holes that only show up under load) and integration with your context. We do that part with you, so you start from a proven base instead of a blank page.

You don’t need an MCP for everything: it’s a common mistake that adds needless complexity. If a service already has a clean CLI or a well-made API, you can often use it directly and be done. A dedicated MCP pays off when you want to standardise access to that service for several agents, reuse it across different projects and give the model a stable interface. It’s a trade-off between speed and reuse, to be decided service by service: together we assess where an MCP is worth building and where a CLI or API is more than enough.

There’s no absolute “best”: it depends on what you put in. For short, stable facts a lightweight file-based memory works well; for broad knowledge you need a vector store with retrieval; for versioned documents an MCP that talks directly to the repository is the way to go. The risk is setting up a more complicated stack than necessary and ending up having to maintain it. We give you the stack we actually use for our own knowledge base — already tested, with its known limits — and adapt it for you, so you start from something that runs.

We don't have a price list: every project is priced on quotation. It's boutique work, tailored to your processes and hard to standardise. The quote comes after the discovery call, once we know what needs doing.