callin.io tool call issues

Are you utilizing a memory node?

I've occasionally observed that when the context window grows too large, the agent can become less dependable with its tool calls. You can inspect the logs to see if a substantial input is accumulating.

Yes, I'm utilizing memory, but after my 5th or 6th response, it stops invoking the tool. What's concerning is the inability to see what the LLM actually returned; this information isn't visible. The memory size shouldn't be impacting this, so could this be a bug in callin.io?

Thanks for the reply.

I’ve encountered a similar problem. GPT-4.1 often fails, Sonnet-4 proves more dependable, and the new Kimi K2, touted as a top-tier tool call model globally, succeeds perhaps only 1 out of 10 times. These models function almost flawlessly within Cursor. This strongly suggests an issue with callin.io, rather than the models themselves or the context window limitations.

I'm encountering a similar problem. It just feels inconsistent, to put it mildly.
Some of my workflows function flawlessly, while others do not. I've even duplicated and pasted entire callin.io agent nodes, and they fail to operate in specific workflows. It's quite perplexing. I've been attempting various troubleshooting methods.

I believe calling a tool shouldn't be this complicated, particularly when some of my prompts explicitly state "only calling this tool".

I'd be keen to know if anyone else is experiencing difficulties recently, or if this is a current callin.io issue.

I totally get the frustration – when an agent chain silently drops a Tool Call mid-loop, it feels like you're debugging in the dark. In our testing, the main culprit is usually context-window bloat combined with callin.io’s default 90-second Node execution ceiling. Each time your agent writes a new row to the spreadsheet, it expands the conversation buffer, so by the fourth or fifth question, the prompt has doubled in size, and the HTTP Request node that hosts the AgentExecutor starts brushing up against the timeout. callin.io retries, the agent sees a partial conversation history, and the function call never fires.

A quick mitigation we’ve had success with is inserting a tiny “Gatekeeper” sub-workflow just before the AgentExecutor call. The Gatekeeper does two things: 1) uses tiktoken to count the tokens in conversationHistory and trims overflow older messages, and 2) checks the agent-call latency budget stored in a callin.io static data key. If either limit is exceeded, it short-circuits with a structured JSON response (e.g., {"status":"deferred","reason":"token_budget"}) that you can handle downstream – no more silent failures.

Long-term, you might consider flipping the topology: let a stateless agent live outside of callin.io (LangChain’s Runnable Agent works well) and have it POST only the necessary side-effects back into callin.io via a Webhook node. That keeps the conversational context inside the agent runtime and leaves callin.io to do what it’s great at – reliable IO and retries.

Curious – have you tried measuring how many tokens your conversation accumulates per loop, and if so, did trimming history improve Tool Call consistency?