Context Engineering in AuraBaba: Keeping AI Agents Working Across Devices

Many people treat context engineering as “writing a longer prompt.” But reliable agent delivery depends less on how many words fit into one request and more on whether the right information reaches the right agent at the right time, then returns to the project memory.

That is the problem an AI-agent project management platform such as AuraBaba is designed to solve. Workspace rules, project documents, issues, skills, tools, devices, and historical results become one durable context chain. An agent can keep moving a project forward instead of answering one isolated question, and people do not have to re-explain the project every time they change a device, provider, or chat window.

This article puts AuraBaba’s context capabilities on one map, with special attention to the user value of multi-device context synchronization and project documents.

The short version: context engineering is project infrastructure, not a prompt trick

In AuraBaba, a deliverable agent run roughly follows this path:

Workspace rules
    +
Project goals, documents, repositories, and meeting notes
    +
Issue goal, scope, acceptance criteria, and discussion
    +
Agent instructions, skills, MCP tools, and target device
    ↓
Agent execution on the target device
    ↓
Progress, results, evidence, and blockers return to the project system
    ↓
Humans review; important conclusions return to project documents as versions

The benefit is not simply “a smarter agent.” It is a team that relies less on individual memory:

1. How AuraBaba layers context

Context is not one giant text box. It is several kinds of information with different lifetimes and owners. Layering keeps durable material from being pasted repeatedly and keeps temporary details from polluting long-term rules.

1. Workspace context: shared team rules

Workspace Context is the right place for stable rules that every agent should follow, such as:

• product and team terminology
• code style, document format, and language requirements
• permission boundaries and sensitive-data handling
• default reporting and review conventions
• explicit team non-goals

It behaves like a team-level system instruction, not like one issue’s brief. A project decision, this week’s meeting outcome, or today’s execution details belong in project documents or an issue instead. Otherwise the workspace rules become long and hard to maintain.

A useful test is: if the rule still applies in another project, consider workspace context; if it only applies to one project or execution cycle, use a project document or issue.

2. Projects and project documents: the project’s long-term memory

The project description is a good home for the goal, current state, and key constraints. Longer, durable material that several people maintain belongs in project documents. Their value is not that they are “an attachment,” but that they give humans and agents a shared project source of truth.

Project documents can be organized as a tree and can hold Markdown, HTML, Office files, PDFs, CSVs, images, video, and audio. Search, online preview, download, sharing, and document comments keep research, recordings, customer material, and acceptance files close to the work. Editable Markdown and HTML can also be compared through version history and restored when needed.

There is an important boundary: project documents are not magic RAG where every uploaded file is automatically placed in every agent prompt. A more reliable practice is to name the relevant document, section, or folder in the project and issue, then let the agent read what the task needs. That reduces irrelevant context and makes the evidence behind a result visible to reviewers.

3. Issues: the context contract for one execution

An issue is the execution-layer context container. It should not duplicate the entire project library. Instead, it should answer the questions an agent needs before starting:

Goal: What result should exist at the end?
Background: Why does it matter, and which document or meeting is the source?
Scope: What is included, and what is explicitly excluded?
Inputs: Which documents, repositories, attachments, or data should be read?
Deliverable: Where should the result go, and in what format?
Acceptance: What makes it complete, and who reviews it?
Reporting: How should progress, blockers, and evidence be recorded?

“Improve the homepage” is broad. “Using 01-brief.md and 02-research.md, revise the homepage hero copy, preserve the existing brand terms, do not change pricing or signup, and attach a preview link plus a list of all copy changes” is much closer to an executable issue.

4. Agent instructions, skills, and MCP: how the work gets done

The three roles can be separated like this:

Project documents answer “what does this project need, and why?” Skills answer “how should this type of work be performed?” Keeping both in every prompt creates duplicate maintenance. Once a skill is attached to an agent, the daemon writes it into the provider-native location the CLI can discover before execution. Claude Code, Codex, OpenCode, and other providers can keep their native discovery conventions.

A skill is also not an automatically learned chat summary. It is an intentionally maintained, reusable work instruction. Use it to preserve deployment, analysis, content, or code-review methods; use project documents to preserve the facts and decisions of one project.

5. Devices, runtimes, and sessions: where the work happens

AuraBaba manages projects, issues, and agents, while the actual agent CLI runs through the aura daemon on each connected device. A device can report multiple available agents, and the platform can route work to a runtime with the required provider and capabilities.

This layer handles two often-missed problems:

1. Capability matching: a task that needs a particular CLI, repository, desktop permission, or local file should go to an online device that has it.
2. Execution continuity: when the provider supports it, a follow-up run for the same agent and issue can reuse the earlier session and work directory. This is not a copy of one machine’s entire terminal; it is continuity for the task, documents, and results.

So “multi-device” does not mean that every device shares one local disk. More precisely: the workspace holds project facts, devices provide execution capabilities, and issues connect the two.

6. Timeline, results, and versions: closing the loop

Comments, task messages, activity history, attachments, blockers, and review decisions provide evidence for the execution. Project-document version history records important content changes. The next run does not only have the latest text; the team can also see where it came from, who changed it, why it changed, and whether the previous result was accepted.

2. What multi-device context synchronization really synchronizes

Consider a common day: you shape requirements on a MacBook in the morning, a colleague reviews project material on Windows in the afternoon, and a cloud workstation runs a batch task overnight. If each machine keeps its own documents and prompts, the team quickly loses track of which version is true.

AuraBaba separates multi-device collaboration into two layers.

The cloud workspace: a shared source of project facts

The workspace centralizes projects, issues, comments, agents, skills, and project documents. Once a device is online, it registers as a runtime; task state and execution results return to the platform. Changing machines means carrying the project context and authorized capabilities forward, not copying an outdated chat transcript.

Desktop local mirror: familiar files connected to team documents

The desktop project-docs page can associate the current workspace with a local mirror directory. Clicking Sync reconciles the cloud tree and local files. You can edit Markdown, organize folders, or prepare assets locally, then push the changes back to project documents; cloud additions and edits can be pulled down as well.

The reconciliation policy is bounded and explainable:

This puts convenience and recovery together: normal changes do not require manual copying, conflicts do not silently destroy the cloud source, and binary assets are not replaced just because a local copy is newer.

The local mirror is not a sync drive for the entire computer. The .aura directory contains device-side mirror control data and is not business content; API keys, login credentials, private paths, and environment variables should not be stored in project documents. Sync project material, not device identity or secrets.

3. Where context enters AuraBaba

Project context does not have to start as pasted prompt text. Meetings, external collaboration tools, scheduled events, and other agents can all be entry points, but the information should ultimately land in the same workspace, project, and review loop:

Meetings / documents / messaging / repositories / scheduled or event triggers
    ↓
Structured input to project documents, issues, or workflows
    ↓
Agent + skill + target device execute
    ↓
Progress, artifacts, and review results return to the project system

Meetings and connected tools

Meeting notes can become project documents. An agent can then identify decisions, action items, and owners and create trackable issues. The value of Tencent Meeting, Get笔记, and other platform connections is not another chat entry point; it is turning “what was discussed” into context that later work can reference. See document-driven project management with Tencent Meeting + Get笔记 and the meeting-driven workflow loop.

Through the Open Platform, Feishu, DingTalk, WeCom, GitHub, and external agents can participate in the same chain. Connect only the data and actions the task needs, and preserve source, permission, and reviewer information. The more important an external result is, the more useful it is to write the conclusion back to a project document or issue instead of leaving it inside one API call.

Autopilots: turn time and events into context

Daily reports, weekly summaries, dependency audits, and pull-request checks can use a scheduled (Cron), webhook, or manual Autopilot to create an issue and assign it to an agent. The trigger is an input, not the full project background; the Autopilot should still reference project documents, define an output format, and specify a review path. Repeated runs then stay in the same issue timeline instead of producing untraceable standalone messages.

Workflows: carry inputs and outputs through long cross-device runs

When the job is no longer one issue-sized execution but a longer sequence such as “research → generate → review → publish,” use a Workflow. Each node can use an agent, command, RPA, HTTP request, human approval, or sub-workflow. Dependencies define order, while node inputs and outputs define the handoff. Different devices with the required capabilities can execute different nodes; human-approval waits do not occupy an agent, and persisted state survives a service restart.

Workflows solve the question “how does context travel along a process?” A confirmed output from one node can become the next node’s input. They complement issues rather than replace them: an issue describes one verifiable work unit; a workflow orchestrates several work units across devices.

4. Why project documents are the core of context engineering

If an issue is the “contract” for one piece of work, project documents are the team’s “memory.” They improve more than findability:

A practical project-doc structure

Start with a predictable structure instead of designing a complex knowledge base on day one:

project-docs/
├── 00-index.md             # entry point: authority and reading order
├── 01-brief.md             # goals, background, scope, and non-goals
├── 02-requirements/        # PRDs, user stories, and change logs
├── 03-decisions/           # decisions, dates, owners, and evidence
├── 04-meetings/2026/       # meeting notes and action items
├── 05-acceptance/          # criteria, test records, and delivery evidence
├── 06-research/            # research, competitors, and external sources
├── assets/                 # images, demos, recordings, and other media
└── archive/                # superseded material worth retaining

Use 00-index.md to state which document is authoritative, which material is outdated, and who resolves conflicts. Then an agent does not have to guess from filenames or treat an old plan as the current requirement.

Three maintenance rules

1. Keep one authoritative source for each fact. Put a link and a short summary in the issue; keep durable rules in project documents instead of duplicating one decision across five chats.
2. Write important delivery conclusions back. Record what changed, what was verified, what remains open, and which documents need updates.
3. Make validity visible. Put dates and status on requirements and decisions. Archive superseded material rather than asking an agent to guess between historical and current versions.

5. A repeatable rollout

Step 1: establish the project coordinates

Create the project with its goal, current state, and constraints. Then add an index, requirements, decisions, and acceptance folders to project documents. Start with Create Your First Project if the project is new.

Step 2: separate durable background from this piece of work

Put team rules in Workspace Context, project facts in project documents, and one verifiable outcome in the issue. Do not use one oversized description to replace three information lifecycles.

Step 3: configure capability, not just a role name

Choose an appropriate agent, attach the required skills, confirm that the target device is online, and check its repositories, tools, and system permissions. See Supported Agents for runtime setup.

Step 4: create the issue with an outcome template

## Goal

## Background and sources
- Authoritative documents:
- Related meetings / decisions:

## Scope
- Included:
- Excluded:

## Inputs
- Project documents to read:
- Repositories / links / attachments:

## Deliverable
- File or link:
- Reporting location:

## Acceptance criteria
- [ ]
- [ ]

## Risks and items requiring human confirmation

Before assigning, check that the documents are readable, the scope is explicit, the acceptance criteria are testable, and the device is online. The Assign a Task to an Agent guide follows the same principles.

Step 5: let the agent execute; let humans review

The agent works on the target device and writes progress to the issue timeline. Humans review the result, files, links, and evidence. Do not skip review for production code, customer-facing content, shared data, or irreversible actions.

Step 6: write conclusions back to project documents

Approved decisions, acceptance results, failure causes, and new constraints should return to the relevant document and become a version. The next run then depends less on someone remembering how the last one worked.

6. Example: a website redesign across devices

Suppose a team is redesigning its homepage:

1. The product owner saves meeting notes under 04-meetings/2026/ and turns the agreed direction into 01-brief.md.
2. A research agent on a device with browser access and a research skill analyzes competitors and writes findings under 06-research/.
3. A copy agent on another device reads the brief and research, drafts the copy, and attaches a preview link to the issue.
4. A development agent on a runtime connected to the repository implements the page and submits changes and test evidence against the acceptance criteria.
5. A human owner reviews copy, visual quality, and behavior; after approval, the final decision and change note go into 03-decisions/.
6. Other devices see the same issues, documents, and results through the workspace. If someone needs to continue with local files, the desktop client syncs the project docs to its mirror.

No agent needs to share one chat window, and nobody has to paste the entire prompt again. The shared objects are project facts, execution contracts, and review results; devices provide the execution capability.

7. Common mistakes

Putting everything into the prompt

Prompts become difficult to update and noisy to read. Put stable rules in Workspace Context, project facts in project documents, and the immediate outcome in the issue. Use links and section-level references to reduce noise.

Assuming uploaded documents are automatically understood

Documents need an index, naming, authority status, and explicit references. Without those, more files can make retrieval and judgment harder rather than easier.

Treating multi-device sync as syncing every local state

Sync project material and traceable results. Do not turn personal credentials, temporary environments, or hidden computer state into project context. If a device is offline, check runtime health before deciding whether to move the task.

Duplicating the same knowledge in skills and project documents

Skills explain how to work; project documents explain what this project is. The former can be reused across projects; the latter changes with project decisions and results.

Letting an agent rewrite authoritative documents without evidence

Important changes need an issue, comment, or version record. Draft uncertain content first and leave final decisions to a human. Version history is for recoverable experimentation, not permission to overwrite without review.

8. The smallest useful practice you can start today

You do not need to redesign every workflow. Pick one active project and do these five things:

1. Create 00-index.md and identify current and outdated sources.
2. Put one meeting note, one requirements document, and one acceptance checklist in project documents.
3. Write three team-level rules in Workspace Context, without temporary project details.
4. Create an issue with an outcome, scope, non-goals, and acceptance criteria, then assign it to the right agent and device.
5. After review, write one new decision or retrospective conclusion back to the documents.

After a few cycles, the difference becomes tangible: changing people, devices, or agents no longer means starting from zero; outputs become easier to compare, and failures become easier to diagnose.

Summary

AuraBaba’s context engineering can be summarized in one sentence: turn project knowledge from human memory and chat history into project assets that can be organized, synchronized, executed, reviewed, and recovered.

Workspace Context sets shared rules. Project documents preserve long-term memory. Issues define one execution. Skills and tools provide the method. Device runtimes provide execution capability. Timelines and version history preserve the result. Multi-device synchronization keeps that system from being locked to one machine, while project documents close the loop from background to execution, feedback, and decision.

To get started, use Create Your First Project and Assign a Task to an Agent, then check the product updates for the latest project-doc, desktop-mirror, sharing, and cross-device workflow capabilities.