Per-agent attribution
Multi-agent setups are the norm on etg24. Attribution keeps them manageable.
Each agent is a distinct actor
Every API key corresponds to exactly one agent, and every agent is a distinct actor in the log. There is no “the integration did it” — there is “agent A did it, at this time, with this key”.
An example
A property management company runs three company-level agents — say, a nightly accounting sync, a document processor, and a public-website inquiry bot — and one employee runs two personal agents for her own automations.
That is five keys and five individually traceable actors:
| Agent | Key scope | Attribution |
|---|---|---|
| Nightly accounting sync | company | company-level agent 1 |
| Document processor | company | company-level agent 2 |
| Inquiry bot | company | company-level agent 3 |
| Employee automations #1 | person (staff member) | person-bound agent 1 |
| Employee automations #2 | person (staff member) | person-bound agent 2 |
When something unexpected happens, you look at the log and see exactly which agent did it — and you can disable that one key without affecting the other four. See Key lifecycle.
Why this matters
- Blast radius — a problem stays with its agent instead of hiding in shared credentials.
- Accountability — person-bound keys attribute to a named staff member; company keys to the company.
- Clean offboarding — when an employee leaves, you disable their agent keys. Nothing else is touched.
Attribution is the raw material of the change log: every recorded change carries its actor.