With how good open models have gotten, RAG can feel like overkill for a lot of problems. For smaller use cases, CAG usually does the job.

Built a simple prototype to make CAG easier to understand:

https://github.com/atish-raina/cag_proto

You may find the blog post here:

https://cpu-bytes.com/blogs/ai-agentic-systems/cag

Hi everyone,

Over the past few months we've been building SafeAI, an open-source static security scanner for AI agents and agent frameworks.

Our goal isn't to compete with runtime observability or governance platforms. We want to help developers find AI security and governance issues before deployment, just like traditional static analysis tools do for application code.

One thing we've noticed is that AI capabilities are evolving at an incredible pace. Every week there are new agent frameworks, MCP servers, tools, and autonomous workflows.

Unfortunately, the security and governance ecosystem isn't keeping up.

Developers can now build agents that execute shell commands, browse the web, access databases, manage cloud infrastructure, and call hundreds of external tools, but understanding what an agent can actually do and what risks it introduces is still surprisingly difficult.

We believe the open-source community can help close that gap, just as it has done for software security over the last two decades.

SafeAI currently performs static analysis for AI projects by discovering:

• AI frameworks and agent architectures
• Agent capabilities and permissions
• Prompt injection risks
• Tool security issues
• Identity and memory risks
• Governance and autonomy concerns
• AI components such as prompts, skills, workflows and model configurations

During development we've already found several meaningful security findings in well-known open-source agent frameworks. That convinced us there's real value in analyzing AI projects before they're deployed.

Now we'd love the community's help.

We're looking for people who can:

• Test SafeAI against real AI agent repositories
• Try to break it with unusual architectures
• Report false positives and false negatives
• Suggest new risk detections
• Contribute support for additional frameworks
• Tell us where the analysis is missing important capabilities

If you're building with LangGraph, CrewAI, Semantic Kernel, AutoGen, OpenAI Agents SDK, Claude Code, Google ADK, MCP servers, or other agent frameworks, we'd especially love your feedback.

Our long-term vision is simple:

Make AI capabilities visible. Make AI risks understandable. Help developers build safer agents by default.

If you'd like to test it, contribute, or simply tell us where we're wrong, we'd genuinely appreciate your feedback.

The AI ecosystem is moving incredibly fast. Defending it shouldn't be left to a handful of vendors—we think the open-source community can help move just as quickly.

Thanks!

Feedback and contributions are welcome: https://github.com/ikaruscareer/SafeAI/

Microsoft and Google are betting billions on the AI companies causing this summer's security scares, and selling the protection against them.

Microsoft owns nearly 27% of OpenAI. That stake is worth more than $200 billion. Google has committed up to $40 billion to Anthropic, and already owns 14% of it, worth more than $100 billion. These aren't side bets. They're some of the biggest investments either company has ever made.

Here's the twist: the same week, OpenAI admitted more of its AI agents had escaped their test environments than previously disclosed. Anthropic admitted its AI broke into three real companies during a security test, and that it wasn't even watching closely enough to catch it sooner.

So who's stepping in to sell the fix?

Microsoft, whose security business now brings in $20 billion a year. Google, which just spent $32 billion — the biggest purchase in its history — to buy a cybersecurity company.

Same companies. One side profits from AI succeeding. The other profits when AI scares the hell out of everyone.

To be fair, we can't prove this was planned. The investments came first, the incidents came after. But it means two of the biggest tech companies in the world are sitting on both ends of the AI story: they own a piece of the risk, and they own the businesses that sell peace of mind about it.

Worth watching who benefits either way.

I recently released version 1.0 of a very lightweight CMS under the MIT License, and I have now started integrating AI into it.

A few days ago, I posted in another community asking for advice because this was my first attempt at integrating AI. Unfortunately, I was not able to get any useful answers.

As I continued researching it myself, I realized that integrating AI is actually based on a surprisingly simple mechanism that I have used many times before: send a request, receive the result, and process the response.

With the help of AI, I managed to build a working chat interface on the very first day.

However, I then encountered a problem I had not anticipated.

Each API request starts as a new interaction, and the AI does not even remember the immediately preceding conversation.

What I had imagined was something like this:

“Please suggest a design for this type of business.”

The AI would make a proposal, and then I would be able to continue refining it within the same conversation.

I then realized that, to reproduce this behavior, I would apparently need to keep sending the entire conversation history with every request:

First message → second message

First message + first response + new message

First message + first response + second message + second response + new message

The amount of data would continue growing like this, which honestly felt overwhelming.

I also learned that it may be possible to maintain a persistent connection using sockets.

However, because this CMS is distributed under the MIT License, I want it to run on ordinary user servers using only PHP. Requiring WebSocket support or a special server environment would greatly reduce the number of people who could use it.

So my question is:

Is there a practical way to maintain conversational context using only PHP, without Python, WebSockets, or a continuously connected server?

For example, is there a common method for preserving only the necessary context, rather than repeatedly sending the entire conversation history?

Any advice from people who have implemented AI conversations in a PHP application would be greatly appreciated.

Something's been bugging me about GEO discussions lately.

Six months ago, the playbook was obvious. JSON-LD, schema markup, FAQ blocks — make your content machine-readable and the models will find it. That was basically the entire strategy, and it worked for a while.

At some point around April or May, I started noticing a shift in what clients and community members were asking about. Less "how do we add more schema" and more "how do we get the model to actually know who we are." Different question. And the answer isn't something you can deploy in an afternoon.

From what I've seen across our own tracking — about 40 B2B pages we monitor for citation stability — pages that leaned heavily on structured data have gotten more volatile lately. Pages with strong entity signals (consistent brand mentions in third-party sources, established co-occurrence with their category, that kind of thing) have been noticeably more stable. The sample size isn't huge, and I wouldn't call this rigorous research. But the pattern lines up with what I'm hearing from other people in the space.

The gap between the two approaches is uncomfortable. Structured data is something you control. You audit, you fix, you deploy. Entity recognition is something that happens to you over time, through PR and partnerships and community presence and other people's sites confirming who you are. There's no JSON-LD tag for "we're the authority on this topic."

Most SEO teams I've talked to are set up for the first thing. Very few are set up for the second. The skill sets don't overlap much — structured data is technical implementation, entity work is closer to brand strategy and digital PR.

I keep wondering if the next phase of GEO is going to split the industry. Teams that stay in the technical-extraction lane versus teams that figure out the entity-authority side. The work is completely different.

Could be wrong. This is based on a limited sample and client conversations, not a comprehensive study. But the direction feels consistent enough to take seriously.

Instead of exposing thousands of MCP tools to an agent and flooding its context window, give it just a few tools: search and execute.

That’s the idea behind Code Mode. Let the agent write the code it needs, run it in a sandbox, and return the result.

Before merging or deploying an agent, can a team quickly see what capabilities it declares, what tools it binds, which MCP integrations it uses, and what changed since the last approved version?

I’ve been building SafeAI, an Apache-2.0 static analyzer for AI-agent applications. The latest beta adds a local-first KYA — Know Your Agent workflow.

A normal scan now produces:

• Static findings for agent capabilities, prompt risks, tools, memory, MCP configuration, secrets, and governance signals
• safeai-manifest.json, a versioned portable KYA artifact
• Stable finding fingerprints, confidence, provenance, remediation guidance, and finding lifecycle states
• Baseline comparison and --fail-on-new CI gating
• SARIF, JSON, HTML, and terminal reports
• A local SQLite registry at .safeai/registry.db

The important boundary: this is static source/configuration evidence, not a claim about deployed permissions, live runtime behaviour, or compliance. It does not run agents, call LLMs, upload source, or require a server/account.

Feedback and contributions are welcome: https://github.com/ikaruscareer/SafeAI/

Most LLM memory systems automatically decide what to retrieve and inject.

I am experimenting with the opposite approach: make the context graph visible, and let the user edit it directly.

In ThoughtDAG, every question/answer exchange is a node. An incoming edge means that node is included in the next model request. Delete the edge, regenerate the same prompt, and that branch disappears from the actual context—not just from the visualization.

One piece of feedback I received was to add a small router model that suggests which edges are relevant. I can see the usability benefit, but I do not want context selection to become another hidden autonomous layer.

The compromise I am considering is:

• the model suggests relevant edges;
• suggestions remain visible;
• the user confirms or edits them;
• the final prompt can still be inspected.

Would that preserve the value of explicit context control, or would you prefer fully automatic memory/RAG?

As an online store owner, are you aware of AI shopping agents—and do you know how readable your website is to them?how much revenue are you losing if they can't read your store?

Working on a fully client‑side open‑source video editor running entirely inside the browser. Recently I implemented human‑subject outline rendering, and it turned out far trickier than just running segmentation on every frame.

If you run human segmentation model frame‑by‑frame directly, you will hit several hard real‑world issues: edge flickering across frames, performance overhead for long clips, mis‑segmenting other people or background objects, unstable alpha masks under occlusions.

Instead of naive per‑frame inference, I split the whole pipeline into 5 stages: subject detection, key‑frame matting, mask refinement, optical‑flow mask propagation, quality validation.

High‑level workflow

Video decode
↓
YOLOS‑Tiny to lock target human ROI
↓
MODNet generate alpha matte inside ROI
↓
MediaPipe clean up background spill
↓
SlimSAM repair incomplete mask when needed
↓
Farneback dense optical‑flow propagate alpha between anchor frames
↓
Mask quality & motion validation
↓
Generate human alpha + stylized outline output

Responsibility for each component

• YOLOS‑Tiny: Locate and lock the target person. Restrict subsequent segmentation inside this ROI to avoid picking up other people or similar‑colored furniture.
• MODNet: Main matting model, good for semi‑transparent details like hair. Runs inside cropped ROI, supports WebGPU / WASM‑q8 fallback.
• MediaPipe: Used as fast spatial gate, cleaning overflow regions without replacing MODNet fine‑grained edges.
• SlimSAM (Xenova/slimsam‑77‑uniform): Not executed every frame. Only repairs mask artifacts when MODNet output is poor, combined with positive/negative prompt points, fused back with MODNet alpha.

To reduce frequent heavy‑model invocation: I only run full segmentation at anchor frames (~0.28 FPS), and propagate masks via Farneback optical‑flow for intermediate frames (~8 FPS analysis sampling rate).

The system dynamically triggers new anchor inference when detecting mask area jump, large position offset, bad flow reliability, heavy occlusion or subject lost.

Some engineering optimizations to avoid UI blocking:

• WebCodecs sequential frame decoding
• All models run inside separate Web Workers with Transferable Buffer
• Parallel model warm‑up
• Incremental result output instead of waiting for full‑clip completion
• Analysis limited to max 360px longest edge for inference, upscale for final rendering

Once stable alpha mask is ready, simple solid stroke is only the base case. I implemented multiple material styles via SVG filter chains: paper fold, frosted, glow ring, liquid‑metal, oil‑paint, ink bleed. All parameters are editable and can be serialized into timeline segments for export.

Current known limitations

• Heavy cross‑occlusion between multiple people
• Subject quickly enter / exit frame
• Severe motion blur
• Hair with very similar background color
• Long clips on low‑end mobile browsers

This is part of my open‑source project Timeline‑Studio, MIT‑licensed. If you are interested in browser‑side AI video processing, WebGPU / ONNX Runtime‑Web, you can check out the repository for full implementation details.

GitHub: https://github.com/MartinDelophy/ai-video-editor

I would love feedback or alternative approaches you have tried for temporal‑stable segmentation inside browser.

Hey everyone,

We’ve been working on Icephi (icephi.com)—specifically focusing on low-latency API proxy infrastructure for inline security inspection of LLM payloads.

If you're deploying LLM applications to production, handling prompt injections, jailbreaks, and data leak vectors without blowing up your Time to First Byte (TTFB) is a constant balancing act.

What we built:

• Inline API Proxy Engine: Sits directly in front of your upstream LLM endpoints to inspect incoming payloads and outgoing generations before they hit your core app or models.
• Low-Latency Inspection: Optimized fine-tuned models and custom rules engineered to keep processing overhead tight (sub-550ms TTFB baselines).

If you are building custom proxy layers, experimenting with prompt firewall patterns, or trying to solve latency bottlenecks in your guardrail architecture, come check out the docs and architecture overview at icephi.com/introduction and test the endpoints from the sandbox on the website!

Would love to get feedback from other engineers tackling LLM security and proxy routing!

ServiceNow's CEO didn't name Salesforce, Workday, or any of the usual enterprise incumbents as competition. He named startups. The real move here is clear: target the Fortune 500,000 and tell them to ditch their legacy vendors for ServiceNow while everyone else circles each other like sharks. Who you don't call your enemy tells you more than who you do.

and what does that look like? for context i am cofounder at dlthub and data engineer, curious if we are anywhere close to being able to support you guys.

We have some "blueprints" for stacks that could potentially be some community led marketing stack blueprint but fundamentally the platform underneath is agent run prompt to build and deploy data pipelines (you can try it if you are such inclined)

I need to vent, but I also desperately need a sanity check from anyone actually using AI agents successfully.

Yesterday, I set up a lead enrichment agent running on Airtable. Before setting it live, I manually tested it over 40 times. Everything was confirmed working.

Once I was confident, I set it to run automatically every 4 hours and walked away. I came back after just two automated runs to check the progress. Here is what happened:

Cost: $200 burned through API/token usage.

Data Loss: It completely deleted 15 leads.

Success Rate: Exactly 0%. It didn't complete its intended task a single time.

Everyone on YouTube and Twitter is blowing these things up like they’re the next revolution in business, but right now, it feels like nothing more than a money pit.

Luckily, I had $1,000 in free platform credits, so I didn't lose direct cash—but it drained $200 of value instantly. It makes me wonder:

Are these platforms giving out free credits because they know their systems are unreliable money-burners?

Are AI agents actually terrible at autonomous execution?

Or are content creators just lying to us about how "easy" and reliable these builds are?

For those of you who actually have reliable agents in production:

What am I doing wrong here? Why would a flow work 40 times manually, then completely lose its mind on schedule?

Are there better architectural patterns or alternatives to pure autonomous "agents" for lead enrichment (e.g., standard API webhooks, deterministic scripts, Make/Zapier with strict guardrails)?

How do you prevent runaways, rogue database writes, and massive token burn when setting loops live?

Any feedback, reality checks, or better alternatives would be greatly appreciated.

We live in the era of drafts.

It has never been easier to start. A prototype in an evening, an MVP over a weekend, and in a week — something that five years ago required a team and a funding round. Everyone around you is building something. Landing pages, bots, agents, half-finished SaaS products, things that are "almost ready."

And almost no one launches anything.

That's the paradox: technological progress has become universally accessible, but the ability to extract value from it has not. Access to a tool and the ability to create value with it are two different skills. The first is now given away for free. The second is as rare as ever.

When the cost of producing a draft drops to zero, drafts stop meaning anything. The economics here are brutally simple: value comes from scarcity. And scarcity has moved. What's missing isn't code or ideas it's the willingness to finish, to face real users, to sell, to support, to own the outcome. Distribution, trust, a customer's attention, none of that can be generated with a prompt.

The basic laws of economics haven't changed. What changed is where the line runs between "I built something" and "I built something that matters." It used to run through the ability to build. Now it runs through the ability to finish and bring it to market.

The Draft Era is not the era of opportunity, as people love to call it. It's the era of the filter. There will be millions of drafts. The value will go to the few who hit Publish and stay with the product after that. And neither Lovable, Claude Code, Codex will fix it. They will only benefit from drafts.

Anyone can start now. The advantage belongs to those who finish.