Owned event types
Consumes
events.iterate.com/telegram-agent/createdowned by telegramBirth certificate for the Telegram facet on an agent stream.events.iterate.com/telegram/webhook-receivedowned by telegramRaw Telegram Update, appended by the webhook door to `/integrations/telegram/{connection}` and forwarded (plus `replyHint` when the update replies to an earlier message) to routed chat/session streams. `botId` is the receiving bot's numeric id (the webhook path segment).events.iterate.com/telegram/send-requestedThe journaled-send intent: a plain Bot API sendMessage payload (text plus any optional params) appended to the session stream by the agent (or the processor's fixed `/new` acknowledgement). Thread-bound: `chat_id`/`message_thread_id` are FORCED from the stream path (payload values are ignored — the message-sent claim records this stream as the message's thread, so a send that went elsewhere would corrupt provenance; use the raw itx.integrations.telegram sendMessage to post to a different chat). The telegram-agent processor is OBLIGED to deliver it and mark it with a `message-sent` event.events.iterate.com/agent/llm-request-requestedowned by agentThe recorded INTENT to run one LLM turn. Carries no id: the request's identity is the offset this event gets on commit. The reduce ignores it when no trigger is pending or a request already is open — a late debounced intent is a harmless stream fact.events.iterate.com/capability-host/script-run-requestedowned by capability-hostA script should run in this capability scope. Before any attempt starts, the code is typechecked against the scope's capability types: a script with a PROVABLE error — a syntax error, or a near-miss typo where the compiler names the fix ("Did you mean 'get'?") — settles straight to an error completion carrying the compiler errors, without ever running (no started event). Everything less certain runs: capabilities are provided dynamically and declared types can lag the runtime, so bare property/argument mismatches, unknown/untyped capabilities, non-async block shapes, and checker failures all let the script run unchecked.
Emits
events.iterate.com/agents/context-addedowned by agentModel-visible context arrived (user message, developer note, assistant output, system item). The single source of truth for what the LLM sees.events.iterate.com/telegram/send-requestedThe journaled-send intent: a plain Bot API sendMessage payload (text plus any optional params) appended to the session stream by the agent (or the processor's fixed `/new` acknowledgement). Thread-bound: `chat_id`/`message_thread_id` are FORCED from the stream path (payload values are ignored — the message-sent claim records this stream as the message's thread, so a send that went elsewhere would corrupt provenance; use the raw itx.integrations.telegram sendMessage to post to a different chat). The telegram-agent processor is OBLIGED to deliver it and mark it with a `message-sent` event.events.iterate.com/telegram/message-sentowned by telegramOne journaled send delivered to Telegram. On the session stream it is the effect marker satisfying the send-requested at `requestOffset`; on the connection stream it is the provenance claim (`messageId`, `chatId`, `sessionPath`, `request`) the router reduces so replies to bot messages resolve to their exact thread.events.iterate.com/capability-host/script-run-requestedowned by capability-hostA script should run in this capability scope. Before any attempt starts, the code is typechecked against the scope's capability types: a script with a PROVABLE error — a syntax error, or a near-miss typo where the compiler names the fix ("Did you mean 'get'?") — settles straight to an error completion carrying the compiler errors, without ever running (no started event). Everything less certain runs: capabilities are provided dynamically and declared types can lag the runtime, so bare property/argument mismatches, unknown/untyped capabilities, non-async block shapes, and checker failures all let the script run unchecked.