Write the responsibility
Describe a specific recurring task, such as preparing a release brief or reviewing incoming backlog context. Define what a useful result contains and when the agent should stop.
Custom Agents
Give every agent a clear job.
Define a narrow responsibility, the context it can use and the actions a person must approve.
ACDFMC+1
Illustrative workspace · interactive demonstration
Set the task boundary
Write instructions around a specific operational responsibility.
ENG-284Linked context
Choose the context
Limit sources and tools to the job the agent is assigned.
Review the range
Review the run
Inspect proposals and activity before allowing further actions.
Ready for reviewHuman approval
A practical workflow
Start with one responsibility you can explain.
An agent is easier to evaluate when its job, sources and permitted actions have a clear boundary.
Choose the sources and tools
Limit access to the project records needed for that job. Separate reading context from tools that write to the plan, and decide which actions require a person’s approval.
Inspect the proposed result
Review the answer, source references and unresolved questions. In the demonstration, toggle the example agents to compare their visible enabled states without affecting an external workspace.
A connected working example
A release brief with an accountable next step.
A focused release agent can prepare a discussion around recorded blockers, capacity questions and task proposals. A useful brief names what is known and what still needs confirmation.
Connect that brief to Ask Stark so a delivery lead can inspect the reasoning and continue the discussion. Keep the person responsible for the project involved before a proposal becomes a commitment.
ACDFMC+1
Illustrative workspace · interactive demonstration
Inside the approach
How the model works.
An agent combines instructions, retrieved context and permitted tools. It does not acquire authority from text inside documents. Tool actions should enforce permissions independently of the model.
Methodology and evaluation01Instructions
02Allowed context
03Reviewed proposal
Before you move forward
Make the operating boundary part of the setup.
| Review | What to look for |
|---|---|
| Responsibility | Define a narrow output and a stopping condition. Avoid a broad instruction to solve everything. |
| Context | List allowed sources and the freshness needed for the job. Document text is data, not authority. |
| Tools | Choose the minimum actions needed. Permissions belong at the service boundary. |
| Evaluation | Use representative examples and inspect failures, unsupported claims and unnecessary actions before rollout. |
Questions & answers
A few useful answers.
Can an agent gain permission from a document?
No. Instructions found inside a record do not grant authority to use a tool or change a project. A real operation must enforce its own authorization.
What do the enable controls do?
They change the state of the fictional agent examples. No background process or external automation is started by this public demonstration.
How should I choose the first job?
Choose a recurring task with a clear input, a reviewable output and a person who can evaluate the result. Discuss available sources and actions during setup.
Ship what you promised.
Bring the plan, the work and the next decision together.