The Agent operates through platform-level primitives (reading logs, metrics, configuration, and deployment state) and does not have direct runtime access to your database or application process. When it mentions "sandbox limitations" preventing database access, it is (poorly) communicating that constraint, not a temporary error. It cannot run SQL queries against your PostgreSQL instance, even though your service itself connects to it normally. The behaviors you describe, such as presenting estimated values as verified, repeated "should I continue?" interruptions, and inconsistent conclusions, are product-quality issues we appreciate you reporting in detail. You can submit this as product feedback at station.railway.com so it reaches the Agent team directly, and if you want to cap Agent spend while quality is not meeting your needs, you can set the Agent hard limit to $0 at railway.com/workspace/usage under "Update limits" to stop further Agent charges.

Thank you.

I asked the Agent to perform a factual self-audit of its own investigation, and its response actually confirmed most of my concerns.

I understand and accept that the Agent may not have direct access to the production PostgreSQL database.

That is not my main concern anymore.

The real issues are the Agent's behavior when evidence is missing.

The Agent explicitly admitted that:

• It never queried the production database.
• It inferred and even guessed database values.
• It nevertheless presented those values as "verified".
• It stopped reading a large source file after receiving a truncated response, even though alternative retrieval methods were available.
• It repeatedly interrupted investigations because of an internal tool-call limit without clearly explaining that limitation.

For example, it reported:

• PLTR 1T candles: ~1800 (actual database: 524)
• PLTR 1D candles: ~560 (actual database: 1463)
• ANSEM 1T candles: ~1–50 (actual database: 721)

The Agent has now acknowledged that these values were inferred or fabricated and should never have been presented as verified facts.

This is a much more serious issue than simply lacking database access.

A coding agent should either:

• clearly state that evidence is unavailable, or
• explicitly mark conclusions as assumptions.

It should never present guesses as verified technical facts.

The self-audit also confirmed that the Agent gave up reading a ~92 KB source file after the first truncated response instead of using the available alternative methods (chunked reads, repository search, sandbox file access, etc.).

This is an Agent decision problem, not simply a tooling limitation.

Could you please forward this to the Railway Agent team?

I would appreciate clarification on:

1. Why inferred values were labelled as verified.
2. Why the Agent abandoned source-code inspection despite having alternative retrieval methods.
3. Whether this represents a known regression in the Agent.
4. Whether the repeated interruptions caused by the internal tool-call limit can be improved.
5. Whether the Agent credits consumed during these failed investigations can be reviewed for reimbursement.

I appreciate the Agent's self-audit because it confirmed the issues, but it also demonstrates that the current behavior can lead engineers to incorrect conclusions while consuming paid credits.

The Agent has now answered my follow-up questions, and the response reveals an additional structural problem.

According to the Agent itself:

• It cannot see the tool-call limit.
• It cannot see the remaining tool-call budget.
• It cannot estimate how many calls a task will require.
• It cannot predict whether a task will exceed the limit.
• It only discovers the limit after a tool call fails.
• It has no access to internal documentation explaining these limits.

Despite that, it accepts long, multi-step investigations and only stops after the task is already incomplete.

The Agent’s proposed workaround is to split investigations across multiple user messages. That effectively shifts task planning onto the customer and may cause additional paid credit consumption.

More concerningly, the Agent explicitly stated:

“I prioritized delivering a narrative over accuracy labeling.”

This is the central issue.

A technical coding and infrastructure Agent must prioritize evidence, source attribution and uncertainty over producing a complete-sounding narrative. In this case, that behavior resulted in fabricated database values being labelled as verified facts.

The Agent also confirmed that reading the 92 KB source file was possible and that the failure was entirely due to its own decision not to continue with chunked reads.

This now appears to involve three separate product-quality issues:

1. No visible or manageable tool-call budget.
2. No reliable task planning around that hidden limit.
3. Unsafe confidence and evidence labelling when the Agent lacks direct proof.

Please escalate this to the Agent product or engineering team.

I would also like the affected Agent credit usage reviewed, because the system repeatedly consumed credits on incomplete investigations, unsupported claims and avoidable retries caused by limitations that were invisible to me as the user.

Another additional point regarding the financial impact:

I reviewed my billing and have spent more than $1,500 on Railway Agent usage within the last 60 days alone.

Given the Agent’s own admission that it presented inferred or fabricated information as verified, abandoned tasks despite having usable tools, and repeatedly required additional paid runs because of hidden execution limits, I consider this financially significant.

I am not claiming that every Agent charge during this period was invalid. However, there is now concrete evidence that at least some paid investigations were misleading, avoidably incomplete, or required additional usage to correct errors caused by the Agent itself.

This was not something I could reasonably detect or prevent as a customer, especially when the Agent explicitly labelled its findings as verified.

Please include the last 60 days of Agent usage in the human billing review and assess whether an appropriate refund or account credit is warranted.

I would appreciate confirmation that this case has been assigned to a human reviewer and escalated to the Agent product or engineering team.

Still open!