Hermes Mixture of Agents (MoA) explained. Every agent commits to a single model, and every model has blind spots the others would have caught. The usual workaround is to run the same prompt through a few models by hand and reconcile the answers. It works, but it lives outside the agent, so the tools, the memory, and the session are gone the moment that detour starts. Hermes Agent by Nous Research just shipped Mixture of Agents, which folds that whole process back inside the agent. The unit you work with is a preset. Think of it as a recipe that names a few models to consult and one model to write the final answer, saved under a label you can reuse. So a preset might list GPT-5.5 and DeepSeek as the models to consult, with Opus as the one that replies. You set it up once, give it a name, and pick it later like any other model. The models you consult run first and quietly hand their analysis to the one writing the answer. That final model is the one that actually replies and makes the tool calls, now informed by several perspectives instead of one. Here is the part that makes it click. The preset shows up as a model, not as a framework to wire together. So everything that already works in Hermes keeps working. Tool calls, follow-up iterations, memory, and the same session context behave exactly as they do with a single model, because to the agent loop it is a single model. The models can come from anywhere. One preset can mix OpenAI, Anthropic, DeepSeek, and Google, and it is not capped at two. A few things follow from that design. → It composes a model instead of choosing one. Several models covering each other's blind spots can beat the strongest one on its own. → It stays cheap to run. The models you consult see a stripped-down view of the conversation, so the extra calls stay light and the main context keeps its cache. → It reaches past any single frontier model. Combining the providers already on hand assembles a composite that can outscore the best one available alone. → It is a dial, not a default. It turns on for the hard ten percent of tasks where a second opinion matters, and stays off for routine work where speed wins. Nous reports the effect on its own benchmark. A preset running Opus-4.8 over a GPT-5.5 reference scored higher than either model alone, by roughly six points and eight to eleven percent. The lesson is not that one model has to win. It is that the best answer rarely comes from a single model, and the agent should make blending them as easy as picking one. That said, if you're looking to set up Hermes, I wrote a full deep dive covering the Hermes agent's architecture, memory system, self-evolving skills, GEPA optimization, and how to set up multiple specialized agents. The article is quoted below. You can also watch my YouTube crash course on the Hermes agent: youtube.com/watch?v=bNp6YcKB…

AI security goes far beyond AI. Adding an LLM call to a product puts security focus primarily on prompt filtering, output guardrails, and input validation. That is crucial, but it only covers the application layer, and an equally important infra layer needs its own controls. To understand this, trace a single model call. The prompt leaves the app, hits a provider endpoint, and depending on their retention policy, it sits in external logs for days. If that prompt carries any regulated/private data, it moves beyond the app's boundary. This isn't a failure of prompt filtering since it only governs what goes into the model, and it does not enforce where data can travel/who can store it. Beyond application-layer controls, two infrastructure-level concerns need their own coverage: 1) The first is per-request. Every model call moves data outside the app boundary. Who can access it in transit? Is it scoped to the right tenant? 2) The second is posture drift. Do providers retain the data, and for how long? Can one tenant's prompts reach another tenant's context through unintended disclosure? And do the AI outputs stay inside the compliance boundary that enterprise deals require? Teams typically solve both in the application code, where each new AI feature gets its: - own scoping logic - own encryption - own logging Ten features mean ten separate implementations of the same controls. Moving both to the infrastructure layer simplifies this. - If IAM policies control which services can call which endpoints, every new model call will inherit that boundary automatically. - VPC isolation keeps tenant traffic apart at the network level. - Encryption covers every data flow by default. Every API call, including model calls, gets logged without the feature code handling any of it. @awscloud builds this as the managed infra and they have partnered with me today to explain how it works. Model calls through Bedrock or SageMaker inherit the same IAM, VPC, encryption, and CloudTrail boundaries as every other service. For instance, IDEMIA runs this pattern in production. The company handles identity data for 45+ US government agencies. After moving to containers on Amazon EKS in AWS GovCloud, they cut costs by 30% and sped up delivery by 4x, with the security coming from the infrastructure, not the application code. You can read more on how AWS supports ISVs building this way → fandf.co/4d23iNH Also, I wrote a detailed breakdown of the 11 components in a production agent harness, the full software layer that wraps an LLM. This post covers what sits underneath it. The harness is only as secure as the layer it runs on. Read it below.