Emily: Autonomous Coordination Agent

An autonomous coordination agent that turns goals into tracked decisions, routes them to the right people, waits across async human replies, and closes work only when every blocker is truly resolved.

Comment

Inspiration

The hardest work in a team often does not fail because nobody knows what to do.

It fails between people.

As an engineering leader, I kept seeing the same pattern: a launch was blocked by a decision, another team was waiting for sign-off, one person had answered and another had not, and somebody had to remember all of it.

That somebody became the human workflow engine:

  • remember what is still blocking the work
  • figure out who needs to decide
  • ask them
  • wait
  • follow up
  • reconcile what changed
  • determine whether the work is actually complete
  • report the result back to everyone who cares

AI agents are becoming very good at doing work themselves. But a huge amount of organizational work cannot be completed by one agent because the next step belongs to another human.

We built Emily for that gap.

Tell Emily what needs to get done. She coordinates the people and decisions required to get it there.

Humans remain the decision-makers.

They stop being the workflow engine.

What it does

In our demo, the operator gives Emily one task:

Get the Checkout pilot ready for Monday's beta. The payment retry policy and QA sign-off are still unresolved.

That is the only operator instruction.

From there:

  1. Emily reasons about the task using Gemini through Google ADK. She grounds against workspace knowledge and launches a governed coordination Goal.

  2. The coordination runtime creates durable Conditions for what must become true. Each unresolved decision is routed to its designated accountable owner — in the demo, one to a Payments Engineer and another to a QA Lead.

  3. The workflow parks while those humans decide. Nobody has to keep prompting Emily to check whether something changed.

  4. Human replies become events. When an owner responds, the reply wakes the workflow automatically. The runtime evaluates the relevant Condition, persists the new state, and continues from where it stopped.

  5. The workflow survives across time and human boundaries. If one decision is resolved and another is still outstanding, Emily does not need an operator to restart the process.

  6. Completion is structural, not conversational. Emily cannot make a Goal complete simply by saying it is done. Closure is a server-side state transition guarded by the required Conditions. If the required state is not true, the runtime refuses closure.

  7. When every required Condition is satisfied, the Goal closes and the initiator receives a closure brief.

One task. Two accountable humans. Two asynchronous decisions. Zero operator follow-ups. One Goal autonomously driven to verified completion.

Why this is different

Most autonomous-agent workflows are easiest when the agent itself can execute every next step.

Real organizations are messier.

A payment engineer may need to choose a retry policy. A QA lead may need to approve a release. A product owner may need to resolve scope. Those decisions cannot simply be invented by an LLM.

Emily treats those human decisions as events inside an autonomous workflow, rather than requiring humans to operate the agent.

That creates a deliberate separation:

Gemini decides what to do next. The coordination kernel decides what is true.

Gemini reasons about the task, selects tools, and drives the coordination.

The durable runtime owns:

  • Goals
  • Conditions
  • workflow state
  • events and wake-ups
  • governance boundaries
  • completion

The LLM can drive the work.

It cannot redefine reality.

How we built it

Emily is built with:

  • Google Gemini 3.5 Flash for reasoning
  • Google ADK (Agent Development Kit) as the agent framework
  • Google ADK McpToolset for tool access
  • Model Context Protocol (MCP) as the coordination interface
  • Google Cloud Run for the deployed Emily agent
  • Python for the agent
  • TypeScript / NestJS for the coordination runtime
  • PostgreSQL for durable workflow state
  • Redis for asynchronous worker and event coordination

Emily receives a deliberately narrow MCP tool surface for operations such as:

  • retrieving workspace knowledge
  • submitting a coordination Goal
  • reading Goal and Condition state
  • reviewing governed proposals
  • requesting Goal closure

The coordination kernel's internal planner operations are deliberately not exposed to Emily.

That boundary matters.

Giving Gemini every internal state-changing operation would create two competing sources of authority. Instead, Emily can drive the workflow while the coordination runtime remains authoritative for durable state.

Architecture

                    Tell Emily what
                    needs to get done
                           |
                           v
                 +-------------------+
                 |       Emily       |
                 | Gemini 3.5 Flash  |
                 | + Google ADK      |
                 +---------+---------+
                           |
                      narrow MCP
                           |
                           v
               +-----------------------+
               | Coordination Runtime  |
               |                       |
               | Goals                 |
               | Conditions            |
               | Events                |
               | Governance            |
               | Completion Gate       |
               +-----+-----------+-----+
                     |           ^
                     |           |
               asks / routing    | replies
                     |           |
                     v           |
                +----------------+
                | Accountable    |
                | Humans         |
                +----------------+

                           |
                  all Conditions true
                           |
                           v
                      Goal CLOSED
                           |
                           v
                    Closure brief
                    to initiator

There are two fundamentally different loops here:

Reasoning loop: Gemini decides how to drive the task.

Coordination loop: durable state survives while humans work, events arrive, Conditions change, and the Goal progresses.

That separation is what allows Emily to wait for humans without requiring humans to keep operating Emily.

Challenges we ran into

1. Keeping the agent and runtime from competing for authority

The coordination runtime already owns durable workflow transitions.

If Gemini also received every internal planner operation, we would have created two systems capable of manipulating the same workflow independently.

We solved this with a deliberately narrow MCP boundary: Emily gets enough capability to drive coordination, while the runtime remains the single authority for workflow state and completion.

2. Making asynchronous coordination actually autonomous

A workflow is not meaningfully autonomous if someone must return after every external response and type:

check again

Human replies therefore become durable wake events.

The workflow resumes automatically, evaluates what changed, and continues without another operator instruction.

3. Making completion trustworthy

LLMs are good at generating confident statements.

A confident statement is not evidence that work finished.

Emily therefore does not own the meaning of CLOSED.

Required Conditions must be satisfied before the server permits the Goal to transition to completion.

4. Designing for work the agent cannot do itself

The interesting problem was not replacing humans.

It was allowing humans to retain authority over their decisions without making those humans responsible for driving the workflow around those decisions.

That distinction became central to Emily's design.

Accomplishments that we're proud of

We built an end-to-end autonomous coordination workflow where:

  • one plain-English task becomes durable coordination state
  • multiple unresolved decisions can belong to different humans
  • asks are routed to the appropriate designated owners
  • the workflow parks asynchronously
  • human replies wake it automatically
  • progress persists across replies and time
  • no operator follow-up is required
  • completion is verified by server-side state
  • the completed loop reports back to its initiator

The execution shown in our demo uses Gemini + Google ADK to drive a real persistent coordination runtime. The Goal, Conditions, events, wake-ups, state transitions, and closure are real runtime operations rather than a scripted state-machine animation.

What we learned

The difficult part of autonomous agents is not producing more plans.

It is maintaining trustworthy state while the world changes.

Useful agents increasingly operate in environments where they do not have authority to perform every action themselves.

They need to know:

  • when to act
  • when to wait
  • who is accountable
  • what changed
  • what remains unresolved
  • when an objective has actually become complete

We also learned that restricting an agent's authority can make the overall system more autonomous, not less.

The LLM does not need permission to rewrite reality.

It needs reliable tools for observing reality and moving the workflow forward.

Demo scope

For reproducibility, the demo provisions a fresh workspace and uses simulated team members representing real organizational roles such as Payments Engineer and QA Lead.

The humans are simulated for the demonstration.

The Gemini reasoning, Google ADK execution, MCP tool calls, persisted Goal and Condition state, asynchronous reply events, autonomous wake-ups, server-side completion gate, and closure workflow are real system execution.

No workflow transitions are mocked for the recording.

What's next

Today, Emily can coordinate a task when the relevant owners are supplied as part of the working context.

Next we want her to:

  • participate directly in Slack, Microsoft Teams, and email
  • connect coordination to Jira and other work trackers
  • observe documentation and organizational knowledge
  • discover accountable owners from real ownership records rather than receiving those mappings up front
  • coordinate longer chains of dependencies across teams and tools

The long-term interaction should remain simple:

Tell Emily what needs to get done.

Then let the organization keep working normally while Emily keeps the coordination moving until the task is actually complete.

Hackathon build disclosure

Emily and the emily-agent repository were newly created during the hackathon Submission Period.

During the hackathon we built the Gemini + Google ADK agent, its MCP integration, the coordination-facing tool surface, the asynchronous end-to-end workflow used in this submission, the demo environment, and the Google Cloud deployment.

Emily integrates with Meetless, a pre-existing platform owned by the submitting team that provides the underlying durable coordination runtime.

Meetless is explicitly disclosed here as incorporated pre-existing work.

Built With

Share this project:

Updates