It is possible to do it (ex: run a background process that analyzes memories across customers and updates the system prompt based on the findings). A specific implementation would depend on your application. Feel free to email me [email protected] if you'd like to talk further.
Good question. There a few differences between our approach and shipping an agent with the Claude agent sdk.
1. Our approach has cron-based or trigger-based automations built-in. Building automations with claude agent sdk requires setting up separate infrastructure.
2. Our approach has self-learning built-in. Building a feature like "dreaming" https://docs.openclaw.ai/concepts/dreaming with claude agent sdk also requires setting up separate infrastructure.
3. Our approach decouples the harness and the compute, which lets developers enforce a stricter security boundary, while claude agent sdk ships with the harness, shell, and filesystem in one process https://platform.claude.com/cookbook/claude-agent-sdk-07-hos....
4. Our approach does not vendor lock developers.
You could pick the latest harness and then switch when another better one rolls out. Our bet is that a developer's time is better spent speaking to their customers than switching harnesses.
Developers with customer-facing chat products are the ideal customer.
If a startup has a specific flow they want the agent to take and their traffic is bursty, then I'd recommend using a framework like Mastra and deploying onto a sandbox.
For long-running always on agents where it's important to learn the users preferences overtime, our approach is the highest ROI.
> What keeps users from using the agents for general purpose tasks, protects against prompt-injection, etc?
Users define their agent with a system prompt, tool definitions, and skills (which separate a media generation agent from a people search agent). We use Openrouter which has a prompt injection detection feature: https://openrouter.ai/docs/guides/features/guardrails/prompt....
The most valuable pieces of information an AI agent startup can gather is access to their customer's proprietary data and knowledge of their customers preferences (memory + self-learning).
Even as the cost of writing code goes to zero, those two pieces of information are non-commodities.
Thanks for the feedback. The main idea is that today to built a best-in-class agent, developers build the agent loop, session management, tools, memory, skills, automations (cron + trigger-based), sandboxed deployment, and self-learning.
By providing Hermes with a system prompt, custom tools, and skills, developers get the agent loop, session management, automations, sandboxed deployment, and self-learning for free.
Prism and Higgsfield are both similar in that we bring many AI models into one place. Higgsfield is focused on a number of different use cases - storyboarding, ai filmmaking, and visual effects - while Prism is hyper-focused on short form video.
This is a great point, and I agree with you. If a weight loss supplement brand were to use an AI influencer to market their product, it does raise questions about whether their supplement does in fact work on real people.
Nevertheless, things are trending more in this direction, and AI influencers will soon become the norm. Brands should be required to disclose when their marketing is AI.
It's worth mentioning that AI videos on Prism (and on any platform) do not have to be purely prompt to creative. For example, a brand designer can take an existing creative for a billboard for example and then use AI to generate images of this creative at a train station, in the Louvre, at a bus stop etc (without actually going there and shooting images).
This is a great point. It is challenging to know which models are good at what.
We've found that Seedance is good at photorealitic faces, Kling is fantastic at generating audio (highest quality model in terms of syncing character's face to the words they say imo), and Sora is great at UGC.
This is a great point. I'm assuming when you mention blast radius you're mentioning the risk of the account being banned for being a bot.
One risk with these new standards for agent auth - which we will of course support if our customers want it - is that the websites that need them the most are the least likely to adopt them.
The main use cases for browser agents are for paying utility bills on old government websites or finding receipts for an expense report on a website without an API. There is a no reason to use browser agents on a website like Linear for example. A developer is better off integrating via API or MCP.
Therein lies the main challenge; the websites where browser agents are most useful are the same websites that are least likely to adopt new technology (it was their not adopting new technologies that made them good candidates for this browser agents in the first place).
I think this new standard is awesome, but I fear that the websites that support it will be those websites that didn't need it in the first place (because they could just as easily add an API).
We setup an agent mailbox with Agentmail (https://agentmail.to/). Whoever owns the account (likely the developer) sets up a forwarding rule to this account.
When our agent signs in, we input the forwarded otp code to get access.