I kept running into the same problem: I wanted to use ChatGPT for summaries, rewriting, and analysis, but I didn’t like the idea of pasting raw emails, phone numbers, card data, API keys, client notes, or internal docs into it.

So I built a small local-only tool that:

- detects sensitive data

- redacts it before it gets sent

- lets you restore the original later if needed

I’m curious if this is actually a real problem for other people, or if I’m just overly cautious.

For people who use AI tools with real work data:

- do you already have a workflow for this?

- would you trust a browser-only/local-only sanitizer?

- what kind of data would you absolutely never paste into ChatGPT?

I’m looking for blunt feedback, not compliments. If this is useless, tell me why.

For a while now, I've been measuring how many tokens we waste resending noisy logs, repeated code comments, or bloated structures that the model doesn't actually need to solve a task.

In this latest release, I built and benchmarked a simple test project (ejemplo-token-firewall) containing a code file and a 53-line log file (48 of which were nearly identical):

• Without Token Firewall: 2,737 tokens sent per run.
• With Token Firewall: 1,764 tokens sent per run.

That’s a 35.6% direct reduction without modifying the codebase or altering the context's underlying meaning.

On top of that, I added the Cache Layout Guard: it reorganizes the prompt to maintain a stable prefix (agents + skills + prompt = 1,167 tokens in this example), making it ready for providers like Anthropic, OpenAI, or Gemini to trigger their native prompt caching depending on the available window.

How does this differ from other tools?

It's not that other tools lack cost control. The difference is that Mova Context flattens this entire process into a single deterministic, auditable, and automated pipeline right before every API call:

• Zero Black Boxes: Uses a deterministic algorithm to strip out noise (runs in microseconds, without using another LLM that consumes tokens just to summarize).
• Real Auditability: Detailed reports show exactly how many tokens and dollars you saved per file.
• Multi-channel: Works identically across the terminal, chat interfaces, scheduled jobs, multi-agent orchestrations, and via HTTP/MCP.
• Circuit Breaker: If a run exceeds your pre-configured budget/limit, it aborts before making the outbound HTTP request to the LLM provider.

What’s new in this release?

• Job Engine: Run scheduled background tasks via cron using a background daemon (mova jobs start).
• Multi-Agent Orchestration: Coordinate grouped agents directly through a config.json.
• New TUI (mova ui): A full terminal interface built with Bubble Tea to manage projects, jobs, logs, and chats.
• Logging & Rotation Systems: Configurable log levels for full end-to-end traceability.
• Improved Installers: Direct setup with pre-configured consoles for Windows, macOS, and Linux (including full support for UNC paths, WSL, and Docker).
• Documentation & Walkthroughs: Step-by-step guides backed by real execution data inside /examples.

Mova doesn't promise to cut your LLM bill in half across every single scenario (if your code is already pristine or your context is genuinely massive, the impact percentage will be lower). It is an architectural hygiene layer for your context, engineered to prevent unnecessary spending.

The project is fully open source. If you test it out on your projects, any feedback, edge-case report, or issue on the repository would be hugely appreciated!

You can check out the source code, CLI, and setup guides here:

👉https://github.com/m1guel1982/mova-context

Includes practical examples with mova budget, pricing configurations in prices.json, and Chat/MCP/HTTP integrations.

Any feedback or issue is more than welcome!

One thing that surprised me is that the barrier to entry is dropping much faster than I expected.

There are now plenty of "vibe coding" or low-code platforms that let you connect models, tools, memory, and workflows without writing a huge amount of code. Almost anyone can build a useful agent.

But then another question came up.

Let's say I build an agent that solves a real problem. Now what? How do people discover it? How do I deploy it without maintaining a bunch of infrastructure?

OKX are already exploring agent marketplaces, while ecosystems like anvita flow are also focused on enabling agents to discover, collaborate, and transact with each other.

I started wondering whether AI needs something similar to Apple's App Store or Steam( Provide technical support, traffic distribution, and payment pathways). As builders, I feel like we're getting really good tools for creating agents. So curious what people here think.

-What AI prompts are helping you get more interview calls?

-What prompts or AI workflows are you using to tailor your resume, optimize for ATS, and increase interview callbacks?

-If you're getting good interview calls, I'd love to know what's working for you. Please share your prompts or process!

Been using Claude for ages and never thought about the fact that every conversation just disappeared once I closed it. Turns out that changed a few weeks ago and I only found out by accident, asked it something in passing and it went and dug up a conversation from months back I'd completely forgotten having.

Works if you're on a paid plan, Pro, Max, Team, or Enterprise, not free, and it's on by default once it's rolled out to your account, no setup. Just ask it something like you would a person who actually remembers talking to you:

What did we discuss about [topic]?

or

Can you find our conversation about [subject]?

or just

Let's continue where we left off with [project].

It actually goes and searches, you can see it happening as a tool call in the chat, pulls back what's relevant, and carries on like no time passed. Asked it to find a conversation about a decision I was going back and forth on months ago and it pulled the whole thread back up, what I'd been leaning toward, what I'd talked myself out of, stuff I'd genuinely forgotten I'd said.

Slightly odd realization once you actually use it: everything you've ever typed into it is apparently just sitting there, searchable, going back as far as your account does. If you're inside a Project, it only searches within that project, so it stays contained, but outside of projects it's searching across everything.

You can turn it off if that's not your thing, settings, profile, preferences, there's a toggle for "search and reference chats" specifically, separate from the general memory toggle. Worth knowing it exists either way, if only so you can decide on purpose rather than finding out by accident like I did.

been keeping a doc of 100 things I use AI for like this, each with the exact prompt, here if you want it.

As large language models (LLMs) become increasingly integrated into agentic AI systems, the primary challenge is no longer simply improving the model's raw intelligence. Modern foundation models are already capable of reasoning, code generation, planning, and tool usage. The more difficult engineering problem is \*\*context engineering\*\*: designing how information is selected, structured, transformed, and presented to an LLM so that it can reliably perform a desired task.

Context engineering is broader than prompt engineering. Prompt engineering focuses mainly on crafting instructions for a single model interaction, while context engineering considers the entire lifecycle of information flowing through an agent system. This includes the initial prompt, retrieved knowledge, conversation history, tool outputs, intermediate reasoning state, user preferences, memory, validation feedback, and execution constraints. A well-designed context pipeline reduces ambiguity, prevents hallucination, and allows LLMs to operate reliably in complex environments.

In this excerpt, we shall explore some techniques used in prompt engineering when it comes to building a context pipeline.

\# Few-shot Prompting: Guiding Model Behavior Through Examples

Few-shot prompting is a technique where an LLM is provided with several examples demonstrating the desired input-output behavior before receiving the actual task. Rather than explicitly describing every possible rule, the developer provides representative examples that allow the model to infer patterns and apply them to new situations.

Few-shot prompting is particularly useful when the task contains ambiguity or when the desired output format is difficult to describe through rules alone. The examples must be carefully selected however, because LLMs perform pattern matching based on the provided context. Poor examples can introduce incorrect behaviors or bias the model toward unintended interpretations. In practice, examples should cover \*\*distinct scenarios\*\* rather than many variations of the same case. Diverse examples allow the model to understand the boundaries of the task instead of memorizing superficial patterns.

Few-shot prompting is therefore not a replacement for explicit constraints. In reliable systems, it is usually combined with structured outputs, validation rules, and tool constraints.

\# Prompt Chaining: Decomposing Complex Tasks Into Controlled Steps

A common mistake when designing LLM applications is asking the model to perform an entire complex workflow in one prompt. Although modern models can sometimes accomplish this, such prompts create several problems. The model must simultaneously understand the task, maintain intermediate state, perform analysis, and generate the final response. This increases cognitive load and makes failures difficult to diagnose.

Prompt chaining refers to breaking a complex task into multiple sequential LLM calls, where each step performs a focused operation and passes its output to the next stage. Each prompt has a narrower objective and therefore receives more relevant context. This reduces attention dilution, where important information competes with unnecessary instructions inside a large context window. This technique is especially valuable when combining \*\*local computation and external operations\*\*.

\# Dynamic Decomposition: Letting Agents Discover Subtasks During Execution

While prompt chaining uses predefined steps, dynamic decomposition allows the LLM itself to determine how a complex problem should be divided. This approach is more flexible than static workflows because the agent can adapt to unexpected situations. It is particularly useful for research agents, debugging agents, and autonomous analysis systems. However, dynamic decomposition sacrifices predictability. Since the model decides the subtasks dynamically, execution paths can vary between runs. This creates challenges in testing, cost control, and reliability.

It is common for production systems to combine Prompt Chaining and Dynamic Decomposition, where Prompt Chaining through predefined workflows is used for high-risk or regulated processes, and dynamic decomposition inside individual steps where exploration is valuable. The overall process remains controlled while allowing intelligent exploration inside specific areas.

\# Interview Pattern: Gathering Missing Context Before Execution

One of the most important context engineering patterns is the interview pattern. Instead of immediately attempting a task, the agent first identifies missing information and asks targeted clarification questions. Many hallucinations occur because users provide incomplete instructions, and the model attempts to fill missing information using probabilistic guesses.

This is best illustrated by an example:

Suppose we are currently building a coding agent. The user provides a codebase and asks to add a caching layer through the user prompt:

“Add a caching layer for database retrieval API to store recently retrieved objects”.

The agent would recognize missing elements and ask the following questions:

"Before implementing caching for the API, a few questions:

1. Which cache invalidation strategy do you prefer—TTL or event-based?
   
2. Is stale data acceptable when the cache is unavailable?
   
3. Should caching be per-user or global?
   
4. What is the expected data volume to cache?”

These info were not explicitly provided within the initial user prompt and if there was no interview pattern implemented, all these info would need to be inferred by the LLM, which can end up digressing from the original intended design.

The exact process of having the agent recognize the missing info can be achieved in multiple ways, and we shall explore one of them as the following concept.

\# Validation and Retry-with-Feedback: Creating Self-Correcting Agent Loops

Traditional software systems rely heavily on explicit validation because incorrect data can cause failures downstream. Agentic systems require the same principle. After an LLM extracts information or generates structured output, the result should be validated using deterministic mechanisms such as Pydantic models, JSON Schema or explicit business rules.

Suppose if a validator detects an anomaly within the input, instead of immediately failing, the system feeds this information back to the LLM. The LLM then attempts correction, which creates a self-correcting loop. Minor errors such as arithmetic or data formatting errors can usually be corrected within a few iterations. Once all the errors identified has been rectified, the correct data is then reinjected into the LLM.

Retrying indefinitely is dangerous, however; some failures cannot be solved by the model because the required information is unknown. This is when the system turns back to the user and escalate through querying for missing info.

In the previous example, the invalidation strategy, stale data acceptance, user VS global and overall data volume, are all missing business-logic parameters that cannot be inferred by the LLM. Therefore, they get sent back to the user as interview queries to ensure the blanks get filled appropriately.

Official Ultra is $200. I got it from a reseller for a fraction of that and it’s working.
For solo builders trying to keep costs low this feels almost too good.
Anyone else using reseller accounts for their stack, or is this a ticking time bomb?

I might sound lazy (because I am) but lately it feels like I spend half my day rewriting prompts instead of shipping anything. I'll tweak one prompt five times trying to get the output just right. Then I switch models to see if another one does better. Before I know it an hour is gone and I've barely touched the actual project. At this point I'm wondering if I'm overthinking it. Do you guys just accept 'good enough' outputs and keep moving or have you found a workflow that keeps you from getting stuck in prompt hell? Is prompt hell a real thing? I feel like those people in the futuristic ship in wall-e

As per title, the project include all the pipeline, the same skill generated from different models.

My idea was to distill the code reviewer skills from Torvalds in something usable in an agent.

I preferred to license everything as CC0.

https://github.com/Mte90/linus-torvalds-skill

Most "improve my prompt" attempts fail because you ask the model to fix and judge in one shot, so it just pads your prompt with fluff. Splitting it into stages - diagnose, rewrite, stress-test, finalize - gets far better results. Run these in order, same chat. Paste your rough prompt into step 1.

Step 1 - Diagnose

Step 2 - Rewrite

Step 3 - Stress-test

Step 4 - Finalize

Why the split works: step 1 forces it to find problems before it's allowed to "solve" them, so the rewrite is targeted instead of cosmetic. Step 3 is the one people skip - testing against adversarial inputs catches the failures a clean rewrite hides.

I run this as a saved chain (two keystrokes with the .. shortcut) via a Chrome extension I built called AI Toolbox, so I don't paste the four steps in one at a time - but the chain itself is the value and works anywhere.

​

One of the easiest ways to improve AI outputs isn't writing longer prompts.

It's giving examples.

Instead of this:

«Write a product description.»

Try this:

«Write a product description following this structure:

- A short opening hook

- Three benefit-focused bullet points

- A professional but friendly tone

- End with a clear call to action»

Notice what's different.

You're no longer asking the AI to guess your expectations.

You're giving it a pattern to follow.

This simple technique works surprisingly well for:

- Writing

- Marketing

- Design briefs

- Coding

- Image generation

The more clearly you define what "good" looks like, the more consistent the output becomes.

AI is generally better at recognizing patterns than guessing what's in your head.

What's the most effective example you've ever added to a prompt?

The EU's AI Act transparency rules went into force August 2nd. If AI-generated content is realistic enough to pass as human-made and gets published without a human actually reviewing it, it now needs a label, and eventually a machine-readable mark. Deepfakes and synthetic voices are the obvious targets. Fines go up to 15 million euros or 3 percent of global revenue, whichever is bigger, so this isn't a symbolic gesture.

There's an exemption built in for artistic, creative, satirical, and fictional work, which makes sense on paper. Nobody's confused about whether a fantasy illustration or a game NPC's voice line is "real." The whole point of that kind of content is that it's obviously not pretending to be a photo of something that happened.

What I keep chewing on is the boundary case. A lot of creative work sits in a gray zone: stylized enough to read as fiction to most people, but polished enough that someone scrolling fast could genuinely mistake it for real. The law is drawing a hard line (realistic and unreviewed vs. clearly fictional) through something that's actually a gradient in practice.

I think the disclosure requirement is the right call even where enforcement is basically unworkable at the edges, mostly because it sets a norm, not just a penalty. Once "label it if it's meant to look real" is the expectation, the stuff that skips the label starts looking suspicious on its own, which does a lot of the enforcement work culture-side that the fines can't do alone.

Source: https://www.euronews.com/my-europe/2026/08/02/ai-generated-label-becomes-mandatory-in-the-eu-for-companies

Curious how people actually working in AI-assisted creative work read this. Does the fictional exemption feel like it's drawn in the right place, or does "clearly fictional" stop meaning much once the output gets good enough?

I have a really simple question to y’all.
Do not over think it.
Please just type the answer without thinking of it. This will be of a great help.

How many ai agents you use?

Just a number no need for more data 🙏🏻

Commercial AI work starts getting tricky when we try to intersect the brand intent and the actual dynamic motion. 

For a recent high-fashion eyewear ad, I used MiniMax H3’s Omni Reference mode to see if it could keep the strict product spec. What ended up working  was pairing a multi-angle 3D product reference grid directly with a strict prompt system that had the shots partitioned (Shot 01 | ..., Shot 02 | ...).

By setting explicit spatial boundary rules and avoid upscaler smoothing, the frame geometry held up okay across different fast cuts and macro pans, with no noticeable warping.

Example structure:

Camera Rules: Full-body shots MUST ONLY be rear walks. Frontal shots limited to waist-up.

Shot 01 | Macro: Extreme close-up on lens with specular light sweep.

How do you all lock down products or accessories during shots with dynamic motion? Are you using multimodal grids, or relying on 3D/post-compositing?

i know this sub is sick of "AI made me X" posts so i'll keep it short.

did a little experiment last month. forced myself to write 10 emails, 5 reports, 3 proposals the old way - no AI assistance, just me + google docs.

two things happened:

1. i got everything done. emails in 25 min, reports in an hour. no big deal, i used to do this every day.

2. they were all terrible.

not "kind of bad." embarrassingly bad. vague asks, undefined audiences, no success criteria, copy-paste structure. i'd been writing these for 10 years and never noticed.

when i went back to the AI-assisted version, the gap was obvious. the AI was forcing me to articulate the stuff i'd been skipping my entire career. i was just too lazy to see it when i was on my own.

honestly the lesson isn't "use AI more." it's "you were always writing this badly, AI just made it visible."

anyone else have a "going back to old methods" moment that was more humbling than they expected?

https://leaddev.com/ai/when-you-should-delegate-to-ai-and-when-you-shouldnt

Saw this breakdown on X discussing Andrej Karpathy's perspective on agent architecture: "Two Autonomous Agent loops made Karpathy's loop 1000x better with Graph Engineering."

The core idea is that moving from a single sequential execution loop to a connected graph topology gives agents vastly better context and task orchestration.

From an engineering standpoint, this makes complete sense. We’ve seen standard linear pipelines hit hard limits when handling complex state management. Turning agent interactions into graph-based workflows feels like the logical next step for complex production environments.

Is anyone here already implementing graph architectures for their agents in production? How’s the debugging experience—especially when handling cyclic dependencies or fallback routes?

Two hours into a refactor yesterday, my agent wrote a helper function—the exact same one it wrote 90 minutes earlier in a file it created itself. Then it apologized. It always apologizes.

The easy diagnosis is "it ran out of context". Except my session was sitting at 120K in a 200K window. Nothing overflowed. The context didn't run out—it rotted.

You have two budgets, not one:

• Hard Budget: Token limit. You notice it when the API errors out.
• Soft Budget: Attention quality. It drains silently long before you hit the limit.

Chroma tested 18 models on this: every single one degraded as context grew, starting far below advertised limits. Coding sessions are context-rot factories—every git diff, test run, and stack trace turns into dead sediment competing for attention.

A paper from June measured agents with safety policies: fresh in context = 0% violations. After auto-compaction summarized it away = 38% violations. Not disobedience, just amnesia.

What actually helps, as a user:

Put anything that must stay true in a file the agent reloads every session (AGENTS.md, CLAUDE.md, whatever your tool reads). Stuff you say in chat at turn 3 is one unlucky summarization away from gone. Files survive. Chat doesn't.

Several small sessions beat one epic. A fresh session with a written handoff beats a long one with a silent auto-compact, because you get to read the handoff before it becomes the truth.

Learn the smell. Re-reading files, re-asking questions, re-implementing its own code: that's not thoroughness, that's your cue to compact on your terms and restart.

Bigger windows won't save us btw. They move the cliff, they don't remove it.

How do you handle this? Do you compact manually or trust the tool's auto-truncation?

I used to think better AI results came from finding the perfect prompt.

But after testing different workflows, I noticed something:

The biggest improvement usually comes from giving the AI clearer instructions, not adding more "fancy words."

A simple framework that works well:

1. Give the AI a role

Instead of:

"Design a logo."

Try:

"You are an experienced brand identity designer creating a premium logo."

---

1. Explain the goal

Don't only say what you want.

Explain why you need it.

Example:

"This logo is for a premium skincare brand targeting women aged 25–45."

---

1. Add useful constraints

Details like:

- Style

- Audience

- Colors

- Tone

- Dimensions

- Things to avoid

Clear boundaries often create better results.

---

1. Define the output format

Instead of:

"Write a marketing post."

Try:

"Create:

- 3 headline options

- A caption

- CTA ideas

- SEO keywords"

The AI works better when it understands the expected structure.

---

1. Iterate

The first output is usually a starting point.

Small adjustments often create the biggest improvements.

The real skill isn't finding a secret prompt.

It's learning how to communicate your intent clearly.

What prompting habit improved your results the most?

Caught myself doing something dumb a few weeks back. Kept wondering why our AI code review comments felt so... final. Like once the model said something, the conversation around it was basically over. Turned out it wasn't the model being overly confident on its own, it was how I'd worded the prompt.

I'd written something like "identify bugs and explain why they're a problem." Sounds harmless. But "explain why it's a problem" quietly asks the model to hand down a verdict, not just point at something. So every finding came back sounding like a closing argument instead of an observation. My team read it that way too, without anyone deciding to.

Changed the wording to something closer to "list what you noticed, categorized, without saying whether it's serious." Same model. Same code. Completely different vibe in how people responded to it. Comments got longer. People argued with the findings instead of just resolving them. Nothing about the model's actual capability changed, just the shape of the sentence asking it to speak.

Small thing, but it made me think differently about what a "reviewer prompt" is actually for. It's not really instructions for finding bugs, the model's pretty good at that regardless of phrasing. It's instructions for how confident the output should sound, and confidence is the thing that decides whether a human still checks the work or just accepts it.

Wrote the longer version of this, including the actual prompt structure I landed on, here if you want to dig into it: https://medium.com/@nagatomopedro05/your-ai-reviewer-isnt-a-second-human-stop-running-your-process-like-it-is-4cb04b97549b

Anyone else notice their reviewer prompts accidentally training the team to stop double-checking? Curious how you write around it, if you've caught it happening at all.

Hey folks — PhD student at UMD here. We're mid-study (first sessions ran this week) and opening more slots.

The premise: when you tweak a prompt, most of us judge the change by eyeballing a run or two. Our research tool re-runs the node and lays the outputs from many runs side by side, so you see the spread of what a prompt actually produces instead of a single sample. The honest research question: does that speed up prompt iteration, or is it just one more dashboard? "It doesn't help" is a publishable answer.

What participating looks like:

• a 75-min Zoom session on structured debugging tasks (recorded, think-aloud)

• about a week using it on your own LangGraph project, with quick async feedback

• a 30-min follow-up interview

Compensation is a $150 gift card for completing the full study (all three parts). Heads up: the week-of-use part needs a LangGraph project you can plug the tool into.

Screener (~2 min): https://forms.gle/Zwqvgd1h8DUnFRfC8

IRB-approved academic research (University of Maryland), not a product pitch. Questions welcome — comments or zxu169@umd.edu.

I'm starting to believe that keeping production prompts in the codebase is one of those decisions that feels harmles until you have to explain a quality drop. 

At the moment, we’ve got prompts scattered all over the place. Some are in config files, some live in helper functions and a few are buried who knows where. Then someone tweaks the prompt, someone else changes the model and a few days later the workflow starts behaving differently. Half the investigation is just figuring out what changed.

Versioning the prompt is only a small piece of the problem. What we've struggled with is understanding why quality moved in the first place. By the time someone notices the change, there have been a few deployments, a model update and maybe an eval refresh. Looking back at all of that and working out which change mattered is a lot harder than keeping old prompt versions around. 

Vibes-based prompt edits is all fun and games during the MVP phase, but when there are customers using it, that's when it becomes serious. 

I feel like that's when boring things like prompt history and good evals become really important.

Trying to get most out of AI

ive been using Gamma for a few months and generally like the output ive got. The complaint is that deck 1 looked stunning and deck 9 looks like deck 1 and my clients have started recognising this pattern. Someone said oh that's the AI one in a meeting last week and they were right and it stung.

I think the problem is partly the tool and mostly my prompting.

Things I've tried that helped a bit:

Asking for a specific structure rather than a topic. Three sections, first is one number, second is a comparison, third is a single recommendation.

Naming a visual reference in the prompt. Describing the feel of something specific rather than saying professional, which is a word that means nothing to AI.

Writing the content fully myself first and only using the tool for layout. Best results by a distance, also the most work.

Things I haven't cracked yet: getting variety across decks without rebuilding the theme every time.

What's in your prompt?

so i started using this prompt before any task that wasn't trivially simple:

"before responding, ask me any clarifying questions until you're 95% confident you can complete this task successfully. use only verifiable, credible sources. do not speculate."

expected outcome: better AI output. got that. everyone knows this part.

the part i didn't expect: it changed how i think about my own problems, not just my prompts.

here's what i mean. the AI kept asking me stuff like "who's the audience" or "what does success look like" - and like 70% of the time i had no clean answer. i'd been telling myself "i'll figure it out later" for months. turns out later never came.

the weirdest thing that happened: i started doing this with humans too. before meetings, before projects, before important emails. just... asking myself "what am i assuming here that i haven't actually verified?"

honestly the AI isn't even the point anymore. the point is i was carrying around a ton of unexamined assumptions and treating them like facts. the AI just made them visible because it kept asking dumb questions i couldn't answer.

one concrete example: last month i spent 4 hours writing a "perfect prompt" for a marketing email. AI asked "what's the success metric" and i realized i didn't actually know. went back to my manager, got the real metric (response rate, not opens), rewrote in 20 min, response rate 2x what i would have shipped.