Agentic Context Engineering: Evolving Contexts From Feedback

Agentic Context Engineering, or ACE, updates the information supplied to an AI system using feedback from its attempts. Its evolving context is a playbook of reusable strategies, rather than a model that retrains itself. The original ACE paper↗ (opens in a new tab) explains the research approach.

For everyday work, the useful question is which lessons deserve to influence the next attempt. fenbs offers a human-reviewed place to retain those lessons and project context. It does not implement ACE automatically, but it can keep a useful finding available when your assistant or conversation changes.

What actually evolves in this approach?

ACE changes the input context instead of the model weights, its internal learned settings. It supports both preparation before evaluation and adaptation while a system encounters new tasks.

A work example helps make the distinction concrete. Suppose an assistant prepares revision checklists for a design studio. One attempt mistakes a proposed comment for an approved change. You could correct that answer, but a reusable lesson goes further: before adding a revision, identify its approval evidence and leave unresolved suggestions separate.

The immediate correction fixes one checklist. The lesson may help another checklist if its scope is right. A broad instruction to reject every informal comment would go too far. Context improvement depends on preserving the condition that made the lesson useful, not just keeping a confident sentence.

How do generation, reflection, and curation differ?

The authors’ ACE implementation↗ (opens in a new tab) separates three responsibilities. A Generator attempts a task and produces a record of its work. A Reflector examines successes and errors to extract useful insights. A Curator converts those insights into structured changes to the playbook.

The implementation uses itemized entries with identifiers and helpful or harmful feedback counts. Updates can affect individual entries, and the system merges and refines them rather than requiring a complete replacement of the playbook. These mechanisms make the evolving record inspectable, though an entry and its feedback still need interpretation.

In the studio example, these are different jobs even if one person reviews all three. First, inspect the checklist that was produced. Next, explain the mistaken approval assumption. Finally, decide whether the proposed lesson is specific enough to retain. An articulate explanation of an error is not evidence that its proposed fix will work.

The broader context engineering guide for AI agents covers what an assistant needs while taking actions. ACE adds a particular method for learning what future context should contain.

Why make small updates instead of rewriting everything?

The paper identifies two failure patterns: concise rewrites can lose useful details, and repeated wholesale rewriting can gradually erode the context. ACE addresses these with localized updates and refinement that removes redundancy. The goal is to preserve useful accumulated knowledge while allowing correction.

For a project record, a similar maintenance principle is easy to apply. Correct the approval lesson without discarding the separate instructions about checking page links. Preserve the source of the lesson and its limits. When a person changes a rule, record the replacement rather than silently pretending the earlier choice never existed.

More detail is not an objective by itself. A repeated instruction, an obsolete workaround, and a current exception should not all survive simply because they were once helpful. Ask what each entry changes about the next action. In fenbs, Lessons learned and Decisions and rules keep findings separate from choices people have made.

What would a useful evolving lesson look like?

Consider a hypothetical lesson from the studio’s failed revision checklist. It should preserve enough evidence for a reviewer to understand the problem without reproducing the entire conversation. Here is a practical work record inspired by the idea, rather than a reproduction of ACE’s data format.

• Observed failure: a proposed change appeared on the checklist as if the client had approved it. The source contained a suggestion but no approval.
• Candidate lesson: when building this project’s revision checklist, attach the approving source to each requested change. Put suggestions without approval in a separate list.
• Scope: client revision checklists for this studio project. This does not establish an approval policy for unrelated work.
• Verification: rerun a checklist with one approved change, one rejected suggestion, and one open question. Check that the categories stay distinct.
• Remaining uncertainty: the rule has not been checked against comments that approve part of a larger suggestion.

Keep the candidate lesson provisional until the check supports it. If the next attempt still confuses partial approval, improve the example or source selection before expanding the lesson. Record what the new check actually established. A successful result on one case does not settle every possible interpretation. A lesson in fenbs can preserve those limits alongside the finding for the next connected assistant.

What do the evaluations establish, and what remains open?

The ACE paper reports improvements on selected agent and domain-specific benchmarks. Those results support the tested combinations of tasks, models, feedback, and comparisons. They do not establish that an evolving playbook improves every project or makes arbitrary feedback trustworthy.

One evaluated environment is AppWorld↗ (opens in a new tab), a simulated world of apps used to test interactive coding agents. Its programmatic checks examine resulting state and unintended changes. That is a concrete testing setting, with a different source of feedback from a person giving a quick reaction to a draft.

For your own pilot, preserve the comparison conditions: the model, available tools, task set, starting context, and scoring method. Keep some cases out of the lesson-building process so you can check transfer to unfamiliar work. Measure incorrect actions and missing evidence as well as completed outputs.

Count the effort too. Reviewing proposed lessons, resolving contradictions, and rerunning checks takes time. An improvement that only appears after extensive manual correction may still be useful, but describe that process honestly. The separate research reading guide helps you choose what to investigate next without treating a paper as a product guarantee.

How to do this with fenbs

1. Create a free account and add the project where an assistant repeats useful work. Start with one task whose outcome you can inspect.
2. Record a lesson after a checked attempt: what happened, what you learned, and what to do differently. Link it to the task and preserve the limits of the evidence.
3. Keep a proposed behavior change separate from a rule. A person chooses continuing rules; the assistant can record that person’s decision in Decisions and rules.
4. Connect a supported assistant through Integrations, ask it to read project context before similar work, and save progress when the session ends.
5. Review the next result against the earlier failure. Update the task’s testing record and correct a lesson that proved misleading.

fenbs does not run the Generator, Reflector, and Curator process, score benchmark tasks, or automatically rewrite an ACE playbook. Use a research or application implementation when you need that machinery. fenbs fits the shared work record people want to inspect and carry between supported AI apps.

What safeguards keep a playbook useful?

The paper notes that weak reflection can produce noisy or harmful context, and some tasks need only concise guidance. Treat those as reasons to test the benefit of each lesson. A growing record should earn its place through better work, not through its size.

For a practical pilot, keep original evidence available, make corrections visible, and separate observed failures from speculative explanations. Ask a person to review changes that affect authority or approval. The prompt engineering comparison and context engineering hub provide the broader background for those choices.