I’d treat a vibecoded agent like an untrusted CI job, not like a junior employee: repo-scoped identity, read-only by default, no inherited Actions token or production secrets. Any operation that turns a read into a write should require approval outside the agent’s control and produce an auditable diff. Network egress belongs in the boundary too. Read-only access is not much protection if the agent can send everything it reads to an arbitrary endpoint.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
The source-retention detail seems more important than the model list: if an email is compiled into a wiki and later deleted, or access is revoked, how quickly does that fact disappear from the personal or company wiki? Is the wiki rebuilt from current source state, or are removals handled as a separate event?
Wiki updates happen once a day through. That is when the entire day's context is updated in the wiki. That is when the fact disappearance would take place
The important detail is whether approval binds to the exact proposed action, including the recipient, repository, issue, or data being sent, rather than just “allow Gmail” or “allow this endpoint.” How granular are the gateway policies for APIs where read and write actions share the same host?
jonathan from OneCLI here, yes - approval binds to the exact req by opening it (method, URL, body) when there’s a matching policy defined. then the gateway holds the call and the card shows the parsed payload.
just to clarify how it works - on same host, rules match based on method + path + body, not only the host. for example, GET /calendar/v3/* can be allowed while POST needs approval.
The hard part with these protocols is usually state, not packet formats. Does the spec cover initialization and feature negotiation across different firmware versions, or is that still inferred from one device’s traces?
Everything is inferred from device traces, and compared against known protocol implementations (ex USB - thanks to the openrazer project) - which AFAIK have remained pretty stable over the years.
So far, it's survived a few device firmware updates with no visible breaking changes, but I can't guarantee it always will.
"Over the last few months, we've noticed a significant shift in how people build. As AI models become more capable at reasoning, we've noticed that developers are increasingly relying on new coding agents such as Claude Code/OpenClaw to handle complex tasks." is true when your primary users are developers. But no-code workflow is still valuable at scenarios where determinism is required.
I'm building an agentic compliance platform where every procedure needs to follow company policies and operated on the rigid plan, but the procedure itself is different for every customer. Coding agents could in principle generate the necessary workflow for each company, but they need to integrate with millions of other applications in the company, easy to review and modify.
We built our own workflow builder because every other existing solution is too complicated and doesn't meet compliance requirements. The workflow builder itself was coded by Claude, and it's working wonderfully.
So flowise's shutdown is because their business is targeting a specific sector which doesn't need it anymore, not because workflow builder itself is not useful.
Congratulations on your launch! 4 years of work is certainly remarkable perseverance.
The sync engine feature looks very interesting to me. There have been quite a few products available on the market today, but none has achieved a dominant share yet. So if this is your main strength, I'd like to see more demos built local first.
Curious if you considered shipping the engine itself as a standalone infra piece.
I'm a vercel customer, and I like using vercel AI SDK and Chat SDK. But I found myself moving away from vercel and next.js whenever I start a new project. I wish they maintain the technical standards while achiving commercial success.
reply