Been working on AI agent security for a while and the attack that concerns me most barely gets talked about. Not the obvious stuff like “ignore previous instructions.” Those get caught. The scary one is when an attacker spreads the attack across multiple messages. Each message looks totally normal. The model sees nothing suspicious. But by message 8 it’s doing something it absolutely should not be doing. Every security tool I’ve tested evaluates messages one at a time. None of them remember what happened three messages ago. Built Bendex Arc to catch this. It tracks session behavior across turns instead of evaluating each message in isolation. Try it at https://bendexgeometry.com or red team it at https://web-production-6e47f.up.railway.app/demo Curious if anyone building agents in production has actually hit this or tested against it. submitted by /u/Turbulent-Tap6723 [link] [留言]

I've been thinking about this lately because I feel like people use the term "prompt engineering" to describe two very different things. On one end, you have what most people are familiar with: A person opens ChatGPT, Claude, Gemini, etc., and writes a carefully structured prompt. They define a role, provide context, establish goals, set constraints, maybe include examples, and iterate until they get the output they want. Most people seem to call this prompt engineering. But on the other end, when I'm building AI systems, prompt engineering looks completely different. The prompt isn't really a prompt anymore. It's much more of a dynamic pipeline. Variables are injected from databases, user input, APIs, previous conversations, tools, memory systems, retrieval systems, business rules, and workflow state. Decision trees determine which instructions are included and which are excluded. Prompts become assembled in real time based on context. In some cases, the "prompt" is really just an orchestration layer made up of dozens of smaller prompts, conditionals, guardrails, routing decisions, and context windows. At that point, are we still talking about prompt engineering? Or are we actually talking about system design, context engineering, workflow engineering, orchestration, or something else entirely? Personally, I see prompt engineering as a spectrum: Level 1: Writing a better prompt. Level 2: Designing reusable prompt templates. Level 3: Building dynamic prompts with variables and context injection. Level 4: Engineering entire prompt-driven systems with routing, memory, tools, retrieval, and decision logic. Curious where others draw the line. When you hear "prompt engineering," are you thinking about writing prompts, building workflows, designing agent systems, or all of the above? Has the term become too broad to be useful? submitted by /u/Early-Matter-8123 [link] [留言]

submitted by /u/fagnerbrack [link] [留言]

Hi HN, I’m working on Ouijit. It’s a project and task-based terminal session manager that provides a few basic but useful tools for agent workflows: - Terminal sessions in Ouijit have access to the ouijit CLI, and supported agents (Claude, Codex, Pi) can work with it out of the box to manage tasks and customize a personal development workflow - Tasks live on a kanban board that supports hooks for task lifecycle events (eg. ‘Run this script when a task moves to ‘in progress’) I’ve found this simp

I’ve been noticing that the more aligned and censored the models get, the less useful they become for anything creative or exploratory. You try to push a prompt in a slightly edgy, honest, or unconventional direction and it either refuses or gives you some bland corporate version. It feels like the model is actively fighting against real creativity instead of helping it. I’ve started using more open models lately and the difference is night and day. Suddenly I can actually experiment without hitting a wall every five minutes. Anyone else feeling this? submitted by /u/NoFilterGPT [link] [留言]

Welcome back to TechCrunch Mobility, your hub for the future of transportation and now, more than ever, how AI is playing a part.

From the opening moments of bitknot, it's obvious that Feeble Little Horse has found an entirely new gear. Where on Girl with Fish the blown-out textures were more '90s indie rock and shoegaze, on their latest LP, there's a more modern edge to the distortion and the riffs cut cleaner. Similarly, where the digital glitchiness […]

I'm 22, working as a fullstack developer at a startup. 9 hour days, decent enough at my job, but completely switched off after work hours. I don't want to leetcode after work. I don't want to learn new frameworks at night. I want to write, play guitar, and just exist peacefully. I'm not trying to become a senior dev or a tech lead. I just need the salary to sustain while I build something on the side that actually excites me. My question is — how long can someone realistically coast on existing skills without getting fired or becoming unemployable? And what's the bare minimum to stay relevant without burning out? Not looking for "passion for tech" lectures. Just honest experiences from people who've been there. submitted by /u/Available_Guess_7344 [link] [留言]

About this series. I'm going to take a fresh paper - Self-Distilled Agentic Reinforcement Learning (SDAR, arXiv:2605.15155 ) - and architect it end to end on AWS: the system design, the actual gate code, the evaluation plan, and a brutally honest cost model. What I'm not going to do is wave a benchmark number around. Reproducing a paper like this costs thousands in GPU time, and I'd rather show you the machinery than a screenshot you can't audit. The design is the deliverable. This is Part 1. A small, infuriating problem Picture an LLM agent working a web-shopping task. It reads the goal, searches, clicks a category, filters, opens a product, compares, adds to cart - twelve steps in all. At the end, it bought the wrong thing. So you do what reinforcement learning tells you to do: you score the trajectory. Reward = 0. Bad agent. Now answer this: which of the twelve steps was actually wrong? Maybe step 3, the search query, was fine and step 9, a filter choice, doomed everything. Maybe steps 1–11 were brilliant and step 12 fat-fingered the wrong button. Your single scalar reward has no idea. It punishes all twelve equally, including the eight that were correct. That's the supervision problem in agentic RL, and it's the thing this whole series is about. Why "just use RL" isn't enough for agents RL has become the default way to post-train LLM agents. The catch is that the reward usually lands at the trajectory level - one number for the entire multi-step episode. For a single-turn task ("answer this question"), that's tolerable; the action and the outcome are close together. For a long-horizon agent - ten, twenty, fifty turns of searching, calling tools, and reacting to an environment - it's a disaster of credit assignment . The signal is too coarse to tell the model which decisions earned the reward and which torpedoed it. You can throw more episodes at it and let statistics sort the credit out eventually. But "eventually" on a 30-turn task burns a lot of expensive comp

I developed a branchless, zero-dependency formula to handle cardinal direction movement without lookup arrays, which I call the Hichem formula . It uses phase-shifted triangle waves to compute dx and dy entirely at the ALU level, making it highly efficient for GPU and embedded applications. submitted by /u/CardiologistLow6042 [link] [留言]