Would AGENTS.md work better when starting a completely new project, rather than modifying an existing codebase?
Maybe, but wether it'll be read is still at the discretion of the agent. Claude Code priorities CLAUDE.md - it's not guaranteed that it'll actually read AGENTS.md file.
In the ETH Zurich study, were the tasks limited to bug fixes from GitHub issues, and does that affect how broadly the conclusions apply?
This is representative of the kinds of workflows that developers engage in most often. It's a subset of the workflows that I want to EMA to address. Any workflow that would typically be documented in a Markdown document is fair game.
The study used agent-generated unit tests to validate fixes — were those tests manually verified, and how reliable are they as success metrics?
I don't know.
Does EMA really make execution deterministic, given that LLM outputs can change over time as models update or gain access to more data?
When you use local models, you can lock the version and turn the temperature down to make them deterministic, but that's not the most important way that EMA makes agent powered workflows deterministic. For every workflow execution, you can generate a JSONL document with the journal of every IO event. If the execution is incomplete, you can replay the journal and the workflow will produce exactly same output up to the point where the execution stopped.
In an EMA system with multiple agents, how is the current code state and context shared between agents?
Most agentic framework fall into point to point problem where multiple agents contain internal state. They interact with each other which leads to a tangled mess.
EMA agents are components that execute in a strict top down fashion. Each component has it's own state that it can share it components it renders. The passing of state between components is more like React than anything else. You have to very explicit about what you make available to a child component.
Do agents share a common context window, or does each agent operate with its own limited view of the application?
The parent component's state is the context window but the life cycle of that context is not bound to a scroll position in a context window. The life cycle of context is bound by the life cycle of the component. The state will automatically get cleaned up unless you explicitly propagated it up.
Would EMA typically be used with sub-agents, agent teams, or both, and how does that affect context sharing?
A hierarchy of nested micro agents. Creating an agent is literally creating a markdown document that has a declaration wrapped in <Instructions />
---
inputs:
policies:
type: string
files:
type: string
---
<Instructions>
You're a policy offer, review the following policies
```bash exec
find {props.policies} -type f -exec cat {} +Then review the following files for compliance
find {props.files} -type f -exec cat {} +
```
Produce a report as a table, include status and severity in the table.
<Instructions>This is ^^ is an agent. You can use it like this
---
---
<OfficerAgent policies="policies" files="src/**.ts" />
The blog mentions “Structured Context” — how does this actually work in practice?
The parent/child component relationship allows to bind the life cycle of context to the structure that's inherent to the component execution.
If a project has global engineering constraints (e.g., using Angular signals or ensuring mobile-responsive components), how do you encode those requirements so all agents consistently follow them?
You can render <Instructions /> component at the root and it'll get attached to each sample sent by every agent. This will inject Always use Angular signals into every request to the model.
<Instruction text="Always use Angular signals">
<CodeReviewer />
<PolcyOfficer />
</Instruction>
How would EMA operate in a real multi-feature project, where multiple agents are working on different features simultaneously?
I'm not targeting that use case at the moment, but I'm hoping that it's a question that we'll have an answer to when we get to answering it.
Maybe, but wether it'll be read is still at the discretion of the agent. Claude Code priorities CLAUDE.md - it's not guaranteed that it'll actually read AGENTS.md file.
This is representative of the kinds of workflows that developers engage in most often. It's a subset of the workflows that I want to EMA to address. Any workflow that would typically be documented in a Markdown document is fair game.
I don't know.
When you use local models, you can lock the version and turn the temperature down to make them deterministic, but that's not the most important way that EMA makes agent powered workflows deterministic. For every workflow execution, you can generate a JSONL document with the journal of every IO event. If the execution is incomplete, you can replay the journal and the workflow will produce exactly same output up to the point where the execution stopped.
Most agentic framework fall into point to point problem where multiple agents contain internal state. They interact with each other which leads to a tangled mess.
EMA agents are components that execute in a strict top down fashion. Each component has it's own state that it can share it components it renders. The passing of state between components is more like React than anything else. You have to very explicit about what you make available to a child component.
The parent component's state is the context window but the life cycle of that context is not bound to a scroll position in a context window. The life cycle of context is bound by the life cycle of the component. The state will automatically get cleaned up unless you explicitly propagated it up.
A hierarchy of nested micro agents. Creating an agent is literally creating a markdown document that has a declaration wrapped in
<Instructions />Then review the following files for compliance
find {props.files} -type f -exec cat {} + ``` Produce a report as a table, include status and severity in the table. <Instructions>This is ^^ is an agent. You can use it like this
The parent/child component relationship allows to bind the life cycle of context to the structure that's inherent to the component execution.
You can render
<Instructions />component at the root and it'll get attached to each sample sent by every agent. This will injectAlways use Angular signalsinto every request to the model.I'm not targeting that use case at the moment, but I'm hoping that it's a question that we'll have an answer to when we get to answering it.